On Saturday 19 May 2007, Pete Zaitcev wrote:
> On Thu, 17 May 2007 17:37:22 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
> 
> > > > > > As it happens, USB callbacks cannot be interrupted.  That's a 
> > > > > > somewhat 
> > > > > > artificial restriction; in theory there's no reason we couldn't 
> > > > > > allow 
> > > > > > interrupts.
> > > > > 
> > > > > Do you remember why we're doing this? I did not touch that part since
> > > > > the attempt to keep usb->lock across the callback (read: years back).
> 
> >[...]
> > > I understand the points a-c above. The question is, why do we do
> > > local_irq_save across the URB callback? It seems to be completely
> > > non-functional.
> > 
> > Where is that done?  The HCDs just seem to call usb_hcd_giveback_urb()
> > after dropping their internal spinlock (except the u132 one, which has
> > always been kind of dubious and acts unmaintained).  And that routine
> > doesn't do a local_irq_save.
> 
> Absolutely right, I'm being an idiot here. I think I looked at root
> hub code in the rush to the FreedomHEC preparations. We do not have
> local_irq_save in the giveback routine. So, when Alan wrote "USB
> callbacks cannot be interrupted", he meant normal no-reentrancy
> guarantees, and not that the interrupts are disabled.

And by "normal no-reentrancy" you mean the normal guarantee that
each IRQ handler won't be re-entered while it's running.

I observe that we don't register PCI IRQ handlers with IRQF_DISABLED,
so it's possible that some *other* IRQ happens while it's running;
but most of the non-PCI irq handlers are registered with that flag set.

That seems potentially buglike to me; it's legit for any IRQ handler
to submit an URB.  Which would then cause them to try grabbing the
spinlock held by the HCD's IRQ handler, if that "other" IRQ handler
happened to fire when the HCD's IRQ handler was running.

So maybe we should always register with IRQF_DISABLED, unattractive
though that could be in terms of latencies ... or, somehow try to
define a rule whereby URBs can't be submitted in certain IRQ contexts.

- Dave


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to