Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1

[Duncan Sands <baldrick@free.fr>]

There is another solution by the way, which involves changes in the core:
make dev->serialize into a read/write semaphore, and have disconnect
be called with a READ lock taken on dev->serialize.  Then in usbfs, I can
take a read lock on dev->serialize whenever I want to rummage around
in the device configuration.  This way things can be left as they are (i.e.
keep ps->devsem) and deadlock will not occur as long as usbfs only
takes read locks on dev->serialize.  Of course calls to usb_set_configuration
may deadlock as now unless you drop ps->devsem before calling, but I'm
sure this can be dealt with (this is because it needs a write lock on
dev->serialize).  I quite like this solution because it makes
things more robust: as long as device drivers only take a read lock on
dev->serialize, they should not deadlock for this reason.  (These deadlock
possibilities are a fundamental problem because drivers call into the
core (which makes itself atomic using dev->serialize and friends), but
the core also calls back into drivers via disconnect methods which it
wants to make atomic by holding the same lock).

Ciao,

Duncan.