On Mon, Apr 25, 2005 at 12:33:22PM -0400, Alan Stern wrote: > On Mon, 25 Apr 2005, Roman Kagan wrote: > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=111341625900343 > > I see. This may not be a problem so much with klists as with usbcore. > That is, device_release_driver isn't protected against recursion, but > perhaps it doesn't need to be since usbcore can be changed to prevent > recursion in usb_driver_release_interface.
Well for non-klist version the test !list_empty(&dev->driver_list) in usb_driver_release_interface() was a good enough guard against recursion into device_release_driver(), so I'm not sure your patch is needed. > The other problem I was thinking of is related to the one you found. > Since driver_detach doesn't immediately delete the device from its > driver's list, it's possible that another driver will bind to the device > first and thereby corrupt the list pointers. I'm not sure I get your point. The problem I spoke of was that with klists, device_release_driver() didn't take immediate effect when called from driver_detach(), due to an extra reference from the klist_iter in the loop. That had a nasty effect on usb_driver_release_interface() by making it think that the device was still associated with the driver when it already wasn't. But it certainly didn't make it look as though the device was dissociated from the driver _before_ it actually was, so another driver shouldn't be able to mess things up. Or did you mean anything else I've missed? Roman. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
