On Sun, Apr 22, 2012 at 5:49 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 21 Apr 2012, Oliver Neukum wrote: > >> > 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. > > I see. I never really understood the problem before. > > Although the kerneldoc doesn't actually say so, it should be safe to > assume that usb_unlink_urb calls the completion routine directly _only_ > in cases where the unlink succeeded. (We could add this to the > kerneldoc.) > > Therefore: If the URB completes with status other than -ECONNRESET then > you can safely take the lock for resubmission. If the URB completes > with status == -ECONNRESET then you know it was unlinked, so you don't > need to take the lock -- the race has already been lost. > > Does that solve your problem? Not sure if that does work. If the URB completes asynchronously after unlinking, its status is still -ECONNRESET, so extra race may be caused without holding the lock because complete handler will access some global data. Thanks, -- Ming Lei -- 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
