On Sun, 22 Apr 2012, Ming Lei wrote: > > 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. That would be a completely separate race, right? So maybe it can use a different lock for protection -- and this other lock could be dropped before usb_unlink_urb is called. Alan Stern -- 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
