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, 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


[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