On Wed, Feb 08, 2023 at 09:46:01PM +0100, Troels Liebe Bentsen wrote: > On Wed, 8 Feb 2023 at 17:48, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Here's a patch. It should fix most of these problems. > > > > Alan Stern > > > Thanks, it will give the patches a try. > > But I guess it still means that "lsusb -v" or other tools that try to > read the hub's usbfs file will block until the child device's descriptor read > has timed out as something in that code path takes the hub's device lock. That's right. However, at least you'll be able to kill the process if you have to. > I tried following the code path up from the read descriptors error and it > looks like locking is done on port level with usb_lock_port until we hit > hub_event where usb_lock_device(hdev) is taken, being new to this > code base I'm not sure it's the same mutex we locked on in > read_descriptors, but do we need to hold it until the end of the > function or is the hub device lock taken somewhere else? It is the same mutex. And yes, it needs to be held until the end of the function. Alan Stern
