On Wed, 23 Oct 2002, Oliver Neukum wrote: > Am Mittwoch, 23. Oktober 2002 01:25 schrieb David Brownell: > > >>>IMHO usb_stor_clear_halt and usb_stor_reset_common should take > > >>>dev_semaphore. > > >> > > >>What's the race? > > > > > > usb_stor_clear_halt uses a synchronous control message. > > > It will not be unlinked upon disconnect. Disconnect must not > > > return until the control message has failed. > > > > In that case shouldn't your argument be that all the synchronous > > wrappers for control and bulk should also take that semaphore? > > Better to have one fix address most instances of this problem. > > I'll work through all of them, don't worry ;-) > > > But here's a case where I think it'd be wrong to use a semaphore. > > Some sort of shared lock for routine use, with "unbind driver from > > interface" processing always getting it in exclusive mode, is more > > the right idea ... > > Upon first consideration I'd have thought so, but on second thought > I found no use for a driver sending concurrent synchronous messages > to an interface.
Adding a semaphore is definitely the wrong solution. The problem of immediately cancelling all URBs when a disconnect occurs exists throughout the usb-storage driver, not just in usb_stor_clear_halt and usb_stor_reset_common. It needs to be solved at a higher level. Here's a suggestion that would help all existing usb drivers. Add an additional parameter to usb_control_msg (and the other synchronous message subroutines as well) that takes a struct urb **. The subroutines can use it to store a pointer to the dynamically allocated URB, so that the driver would have the ability to cancel the URB whenever it wanted. (Alternatively, a more object-oriented -- and more correct -- approach would make the additional parameter be a pointer to some sort of handle. This handle could then be passed to a core subroutine that would use it to identify and cancel a synchronous message and delete the corresponding timer as well.) Adding this facility would simplify not only disconnect handling but also scsi-generated aborts in usb-storage. Of course, it would also require altering any driver that sends a synchronous message. Oliver, what do you think? Alan Stern ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
