Driver core: Fix potential deadlock in driver core
authorAlan Stern <stern@rowland.harvard.edu>
Mon, 18 Sep 2006 20:22:34 +0000 (16:22 -0400)
committerGreg Kroah-Hartman <gregkh@suse.de>
Tue, 26 Sep 2006 04:08:40 +0000 (21:08 -0700)
commitf2eaae197f4590c4d96f31b09b0ee9067421a95c
tree5ccb072851da5d1bfdae458c52b57e76eb7dd168
parent0f397f865076e3471ec884ee73ad5e34165fac2a
Driver core: Fix potential deadlock in driver core

There is a potential deadlock in the driver core.  It boils down to
the fact that bus_remove_device() calls klist_remove() instead of
klist_del(), thereby waiting until the reference count of the
klist_node in the bus's klist of devices drops to 0.  The refcount
can't reach 0 so long as a modprobe process is trying to bind a new
driver to the device being removed, by calling __driver_attach().  The
problem is that __driver_attach() tries to acquire the device's
parent's semaphore, but the caller of bus_remove_device() is quite
likely to own that semaphore already.

It isn't sufficient just to replace klist_remove() with klist_del().
Doing so runs the risk that the device would remain on the bus's klist
of devices for some time, and so could be bound to another driver even
after it was unregistered.  What's needed is a new way to distinguish
whether or not a device is registered, based on a criterion other than
whether its klist_node is linked into the bus's klist of devices.  That
way driver binding can fail when the device is unregistered, even if
it is still linked into the klist.

This patch (as782) implements the solution, by adding a new bitflag to
indiate when a struct device is registered, by testing the flag before
allowing a driver to bind a device, and by changing the definition of
the device_is_registered() inline.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/base/bus.c
drivers/base/dd.c
include/linux/device.h