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

[Duncan Sands]

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