Re: [PATCH] hid: usbhid: fix possible deadlock in __usbhid_submit_report

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux