On Thu, 24 May 2018, Martin Liu wrote:
> On Tue, May 22, 2018 at 01:09:44PM -0400, Alan Stern wrote:
> > On Tue, 22 May 2018, martin_liu wrote:
> >
> > > not sure if we still need 'bf74ad5bc417 ("[PATCH] Hold the
> > > device's parent's lock during probe and remove")' since it has
> > > been there over 10 years. If we still need it and hard to fix it
> > > , the simple way is to find a place not to allow USB subsystem
> > > drivers to have async probe capability. Any suggestion is welcome.
> >
> > I don't think the "allows_async_probing" attribute is the best way to
> > attack this. Some other approach, like a special-purpose flag, might
> > be better.
> >
> > Yes, USB still needs to have parent's locks held during probing.
> > Here's the reason. A USB device can have multiple interfaces, each
> > bound to its own driver. A driver may sometimes need to issue a reset,
> > but in USB there's no way to reset a single interface. Only the entire
> > device can be reset, and of course this affects all the interfaces.
> > Therefore a driver needs to acquire the device lock before it can issue
> > a reset.
> >
> > The problem is that the driver's thread may already hold the device
> > lock. During a normal probe sequence, for example, the interfaces get
> > probed by the hub driver while it owns the device lock. But for probes
> > under other circumstances (for example, if the user writes to the
> > driver's "bind" attribute in sysfs), the device lock might not be held.
> >
> > A driver cannot tell these two cases apart. The only way to make it
> > work all the time is to have the caller _always_ hold the device lock
> > while the driver is probed (or the removed, for that matter).
> >
> > Alan Stern
>
> Thanks for the reply and more detail about the backgroud. I'd like to
> have a conclusion about it. Please kindly correct me if my understanding
> is wrong. Regarding to the "special-purpose flag", do you mean we could
> find a place in USB subsystem to have the flag set (not sure if it's
> easy to find it). Driver core would be base on the flag to decide if we
> need to hold the device's parent's lock.
Yes, except that the flag would not be in the USB subsystem. It would
be in the device, device_type, or bus_type structure, so that the
driver core could access it.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
