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. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
