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

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

 



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


[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