RFC USB: HCD/EHCI: giveback of URB in tasklet context
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 4 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
Quoted 10 lines · On Wednesday 12 June 2013 18:11:34 Ming Lei wrote:
Quoted 8 lines · Oliver Neukum
Quoted 4 lines · On Tuesday 11 June 2013 15:10:03 Alan Stern wrote:
In order to prevent this from happening, you would have to change the
spin_lock()call in the completion handler tospin_lock_irqsave(). Furthermore, you will have to audit every USB driver to make sure that all the completion handlers get fixed.Yes. However, it can be done mechanically. And we know only the handlers for complete need to be fixed.
Quoted 6 lines
I am wondering if the change is needed since timer function is still run in softirq context instead of hard irq.
Looks Alan concerned that one USB interface driver may have another hard interrupt handler involved. Is there such kind of USB driver/device in tree?
No. Suppose a USB network driver.
The complete() handler is written on the assumption that interrupts are off. So it takes a spinlock from the network subsystem. It does so with spin_lock()
Other network drivers also take the lock. And they may take it from an IRQ handler. If such an IRQ interrupts the tasklet complete() is running in, the CPU will deadlock.
The danger is not interrupt handlers in the same driver but IRQ handlers of _other_ drivers (PCI, ...) a lock is shared with.
You need to go through all USB drivers and change every spin_lock() that goes for a lock that is exported to a spin_lock_irqsave()
Regards
Oliver