summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2015-12-13 20:12:30 +0300
committerZefan Li <lizefan@huawei.com>2016-10-26 18:15:37 +0300
commit7b4eaec6943f0b7c77e445407215f5730210ed84 (patch)
tree0f819dfae4410513db15befb3279eb186292f78e /drivers
parentd6aefa8720b67e70e715d469ed8c1a5ecb49752a (diff)
downloadlinux-7b4eaec6943f0b7c77e445407215f5730210ed84.tar.xz
genirq: Prevent chip buslock deadlock
commit abc7e40c81d113ef4bacb556f0a77ca63ac81d85 upstream. 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> Signed-off-by: Zefan Li <lizefan@huawei.com>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions