Hi,
continuing my investigation of the effects of the lock added to
video_unregister_device() in 2.4.19, I got reports of yet more drivers that are
broken in a way that is fatal to the system if the camera is disconnected
while open.
I was hoping that usbvideo.c would turn out to be a example that
shows how to close gracefully, but I now see that even that is
probably broken (at best, it might accidentally be OK if
a race gets lost)
In all cases, if the usb cable is disconnected while the camera is open,
the call to video_unregister_device() is deferred till
the final v4l_close() call (which is called during a v4l lock
by video_release() ).
Schematically, what happens is:
video_release()
{
down(&lock);
v4l_close();
up(&lock);
}
void v4l_close()
{
video_unregister_device();
}
void video_unregister_device()
{
down(&lock);
AARGH!
up(&lock);
}
In the only variation I found, usbvideo has
void v4l_close()
{
Release Camera();
}
void ReleaseCamera()
{
video_unregister_device();
}
Which might just get delayed until the up(lock)
in video_release() happens, but if so that is just by
pure good luck.
Note: what happens when the locks clash is *really* evil:
an inevitable
complete system hang when X is closed with the hung locks.
list of broken v4l drivers (since 2.4.19):
cpia
ov511
pwc-if
se401
stv680
usbvideo(?)
On 09-Dec-2002 Tuukka Toivonen wrote:
> Add here:
>
> qce-ga
> qc-usb
>
Was the race condition fixed by the lock
in video_unregister device() so bad that
this breakage is justified?
What was it?
Duncan
