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
