In this case, the simplest solution is simply to insert a test for actconfig != NULL before it gets dereferenced. To make certain that actconfig won't change out from under you, be sure to hold dev->serialize during that test.
No, it is wrong to do that because it may deadlock (the existing use of dev->serialize in releaseintf is wrong because of this): driver_disconnect is called with dev->serialize held and takes ps->devsem, as it must. However almost all routines in devio.c are called with ps->devsem taken, so if they take dev->serialize then they may deadlock with driver_disconnect which holds dev->serialize and is waiting for ps->devsem.
The calls affecting all usb interface binding logic need to also hold the usb write semaphore. Once they hold that, grabbing dev->serialize should behave (respecting the lock hierarchy).
The root cause of some of this stuff is that there are two different binding models in usbcore, with two different implementations and locking schemes, yet they purport to control the same thing.
We can't escape having the two binding models: probe()/disconnect() is the typical one, while claim()/release() is needed by drivers that claim multiple interfaces (like for cdc, audio, and video classes) as well as by usbfs for user mode drivers.
But we can and should fix the different implementations and locking schemes. Removing the "struct usb_driver *" pointer from the "struct usb_interface", and fixing the associated locking mixups, will get rid of some of those oopses. The pointer is redundant, given the dev.driver pointer that's properly maintained through the driver model (and driver model locking).
The real problem is that usbfs is trying to unbind a driver after usbcore has already done so on its behalf. ...
... the whole thing is a mess.... I think the simplest solution is to throw away ps->devsem, optionally convert dev->serialize to a rw semaphore for efficiency reasons (probably doesn't gain you much), and use dev->serialize where ps->devsem was used before. There are a few special cases in devio.c which will need to be tweaked in order for this not to cause deadlocks.
You may be right about ps->devsem. But in terms of layering, I'd have to argue for fixing usbcore (usb_interface.driver) first, to get the lock interactions with the driver model straight, and fixing the "usbfs" code afterwards.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
