Re: klists and struct device semaphores

[Alan Stern <stern@rowland.harvard.edu>]

On Wed, 30 Mar 2005, Patrick Mochel wrote:

> > Having thought it through, I believe all we need for USB support is this:
> >
> > 	Whenever usb_register() in the USB core calls driver_register()
> > 	and the call filters down to driver_attach(), that routine
> > 	should lock dev->parent->sem before calling driver_probe_device()
> > 	(and unlock it afterward, of course).
> >
> > 	(For the corresponding remove pathway, where usb_deregister()
> > 	calls driver_unregister(), it would be nice if __remove_driver()
> > 	locked dev->parent->sem before calling device_release_driver().
> > 	This is not really needed, however, since USB drivers aren't
> > 	supposed to touch the device in their disconnect() method.)
> 
> 
> Why can't you just lock it in ->probe() and ->remove() yourself?

Aha!  There you go...  This explains why you need explicit locking rules.

When probe() and remove() are called, the driver-model core already owns
the device's lock.  If the driver then tried to lock the parent, it would
mean acquiring locks in the wrong order.  This could easily lead to
deadlock.

Furthermore, it will often happen during probe() and remove() that the
parent's lock is already owned by the USB core.  So the driver _mustn't_
try to lock it.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/