Re: Protecting uvcvideo againt USB device disconnect [Was: Re: Protecting usb_set_interface() against device removal]

[Guenter Roeck]

On 8/20/20 3:15 AM, Laurent Pinchart wrote:
[ ... ]

>> usb_set_interface() should not be called anymore after uvc_disconnect(),
>> or at east I think so (is that documented anywhere ?).
>> Yet, that obviously happens, and it happens completely outside lock
>> control. And this is just one instance where I was actually able
>> to see the problem. I am quite sure that there are more.
> 
> Let's hope there are not too many :-) As you can see from the stack
> trace, this happens at .release() (a.k.a. last close()) time. This code
> path is the only one that the V4L2 core can't protect fully for drivers.
> The good news is that there's thus only one code path that drivers would
> need to handle manually.
> 
> I think we could fix this one by calling uvc_queue_release() in
> uvc_disconnect(), after unregistering the video devices. The
> uvc_queue_release() call in the .release() path would then become a
> no-op, as everything will be stopped already.
> 

I'll give that a try.

I plan to add some instrumentation into the code to check if there are any
other usb calls after uvc_disconnect(). We'll see if that was the only one,
or if I can catch more.

Thanks,
Guenter