Hi Alan, Tetsuo, On Mon, Apr 25, 2022 at 12:01:23PM -0400, Alan Stern wrote: > On Mon, Apr 25, 2022 at 12:56:19PM +0100, Sean Young wrote: > > On Mon, Apr 25, 2022 at 08:14:12PM +0900, Tetsuo Handa wrote: > > > On 2022/04/25 18:20, Sean Young wrote: > > > > The problem is there are imon devices which have two usb interfaces, even > > > > though it is one device. The probe and disconnect function of both usb > > > > interfaces can run concurrently. > > > > > > > > Of course, this depends on probe/disconnect functions being allowed to run > > > > concurrently on different interfaces of the same usb device. > > > > > > I don't have real hardware to confirm. If you have an imon device which has > > > two usb interfaces, please try below debug printk() patch in order to see > > > whether the caller is already holding locks for serialization. > > > > I am afraid calling debug_show_held_locks() is not really going to tell us > > this information. This should be figured out from understanding the usb > > stack, not from seeing if the probe happens to be concurrent. > > > > Just because the locks were not held, does not mean that the usb interface > > initialization is not concurrent. > > The driver and USB cores guarantee that when an interface is probed, > both the interface and its USB device are locked. Ditto for when the > disconnect callback gets run. So concurrent probing/disconnection of > multiple interfaces on the same device is not possible. That is very helpful, thank you Alan. I think the original patch as proposed by Tetsuo Handa is correct. However, the commit message does need to say that the lock is not needed because usb core already guarantees this. Please submit a v2 for this. Thank you both, Sean
