Am Samstag, 21. April 2012, 19:31:20 schrieb Alan Stern: > On Sat, 21 Apr 2012, Ming Lei wrote: > > > >> Think about what happens if the URB being unlinked hasn't been > > >> presented to the hardware yet. �Once it has been removed from the HCD's > > >> internal lists, there's no reason not to give it back right away. �And > > >> there's no natural time to give it back later. > > > > > > Now. The question is not when, but from which context. > > > The context should be uniform, so that the requirements > > > for locking should also be uniform. > > > > How about always scheduling a tasklet to run what usb_unlink_urb does? > > just implement usb_unlink_urb as something like > > tasklet_schedule(unlink_tasklet). > > > > Then we can have a uniform lock requirement and no changes are involved > > on host controller drivers. > > The return values would not be correct. > > On the other hand, usbnet could call usb_unlink_urb from within a > tasklet. No. That would introduce a race. Basically whenever a completion handler resubmits itself, any timeout has to avoid a race. Checking for a timeout and unlinking must be atomic, just as the completion handler must make the resubmission and noting the time atomic. If I cannot do this with a lock, then a much more complex pattern is necessary. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
