[RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
Oliver Neukum
oliver at neukum.org
Tue Jun 11 04:49:23 EDT 2013
On Tuesday 11 June 2013 16:14:25 Ming Lei wrote:
> On Tue, Jun 11, 2013 at 3:18 PM, Oliver Neukum <oliver at neukum.org> wrote:
> > On Tuesday 11 June 2013 13:40:20 Ming Lei wrote:
> >> On Tue, Jun 11, 2013 at 1:36 AM, Alan Stern <stern at rowland.harvard.edu> wrote:
> >> > On Mon, 10 Jun 2013, Ming Lei wrote:
> >
> >> If complete() callback runs in one tasklet context, spin_lock() inside
> >> complete() is enough, just like hard irq, the tasklet itself is disabled
> >> during complete(), if the percpu tasklet is converted to single tasklet.
> >> So no problem when the lock is to protect shared resources between
> >> complete().
> >
> > We also have exclusion between complete() and other contexts, i.e. timers.
>
> The patch also converts the complete() called in timers to tasklet context too.
>
> So could you let me know if that eases your concern? If not, could you explain
> your concern about other contexts in a bit detail?
The driver itself may have submitted a timer and race against it.
What locking do you need in complete() and a timer to lock against
each other?
> > Even now we cannot guarantee that all calls to complete() are in irq.
> > There is the case of HCD hotunplug and other cases, like timeouts.
> > They will have to be verified.
>
> All URBs are completed via usb_hcd_giveback_urb(), so there should
> be no differences between these cases and the common one about
> introducing the patchset.
But it makes no sense to go to a tasklet when you are already in task context.
In those cases you need to do something, essentially blocking the tasklet.
Regards
Oliver
More information about the linux-arm-kernel
mailing list