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

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

 



Am Samstag, 21. April 2012, 19:31:20 schrieb Alan Stern:
> On Sat, 21 Apr 2012, Ming Lei wrote:
> 
> > >> Think about what happens if the URB being unlinked hasn't been
> > >> presented to the hardware yet. �Once it has been removed from the HCD's
> > >> internal lists, there's no reason not to give it back right away. �And
> > >> there's no natural time to give it back later.
> > >
> > > Now. The question is not when, but from which context.
> > > The context should be uniform, so that the requirements
> > > for locking should also be uniform.
> > 
> > How about always scheduling a tasklet to run what usb_unlink_urb does?
> > just implement usb_unlink_urb as something like
> > tasklet_schedule(unlink_tasklet).
> > 
> > Then we can have a uniform lock requirement and no changes are involved
> > on host controller drivers.
> 
> The return values would not be correct.
> 
> 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.

	Regards
		Oliver
--
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