Re: klists and struct device semaphores

[Patrick Mochel]

On Thu, 31 Mar 2005, Alan Stern wrote:

> 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.

I should have been more clear. From what I understand, when some devices
are probed they also want to probe and add their children. It *seems* like
this is essentially true with USB devices and interfaces, though I could
be wrong.

What I meant was that when the parent device's ->probe() method is called,
the parent's semaphore could be taken before the children are discovered
and added. This would keep the parent locked while all the fiddling is
going on with the children. Right?


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