On Sat, Feb 17, 2024 at 08:26:11PM +0100, Michał Pecio wrote: > Hi Greg, > > > There are a number of known-race-conditions in the v4l interface that > > can happen when devices go away and userspace is still holding a > > reference on the character device node. > > I wrote to linux-usb because I think this particular crash is a bug in > the USB subsystem - namely, usb_set_interface() appears to crash when > the device is disconnected during its execution. No, the bug is not in the USB subsystem. Drivers are not supposed to call usb_set_interface() unless they can guarantee that the device will not be removed while the call is in progress, generally by holding the device lock. I suppose it could be considered a bug that this requirement is not documented at the start of the function. You could submit a patch adding an appropriate section to the kerneldoc. > Indeed, today I came up with an artificial way to reproduce this crash. > I added msleep(1000) right before the call to usb_hcd_alloc_bandwidth() > in usb_set_interface() and pulled the USB plug when it slept. > > (BTW, previously the device was not physically disconnected, it looks > like the host controller dropped it due to I/O errors). > > Anyway, here's my new crash log: > > # this is what normal execution looks like, nothing special happens yet > [ 210.644611] usb_set_interface called from uvc_video_start_transfer Here you see usb_set_interface() called from the UVC driver under inappropriate circumstances. To fix the problem it will be necessary to fix the UVC driver. It should not allow itself to be unbound from the device while a user-driven operation, such as uvc_video_start_transfer(), is in progress. Alan Stern
