diff options
author | Thomas Gleixner <tglx@linutronix.de> | 2015-12-13 18:12:30 +0100 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2015-12-14 09:45:06 +0100 |
commit | abc7e40c81d113ef4bacb556f0a77ca63ac81d85 (patch) | |
tree | 06c8130b3f1f442a195135e7a032d28b1fa6bbdf /MAINTAINERS | |
parent | 9f9499ae8e6415cefc4fe0a96ad0e27864353c89 (diff) | |
download | linux-abc7e40c81d113ef4bacb556f0a77ca63ac81d85.tar.gz linux-abc7e40c81d113ef4bacb556f0a77ca63ac81d85.tar.bz2 linux-abc7e40c81d113ef4bacb556f0a77ca63ac81d85.zip |
genirq: Prevent chip buslock deadlock
If a interrupt chip utilizes chip->buslock then free_irq() can
deadlock in the following way:
CPU0 CPU1
interrupt(X) (Shared or spurious)
free_irq(X) interrupt_thread(X)
chip_bus_lock(X)
irq_finalize_oneshot(X)
chip_bus_lock(X)
synchronize_irq(X)
synchronize_irq() waits for the interrupt thread to complete,
i.e. forever.
Solution is simple: Drop chip_bus_lock() before calling
synchronize_irq() as we do with the irq_desc lock. There is nothing to
be protected after the point where irq_desc lock has been released.
This adds chip_bus_lock/unlock() to the remove_irq() code path, but
that's actually correct in the case where remove_irq() is called on
such an interrupt. The current users of remove_irq() are not affected
as none of those interrupts is on a chip which requires buslock.
Reported-by: Fredrik Markström <fredrik.markstrom@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions