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? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
