diff options
author | Chengfeng Ye <dg573847474@gmail.com> | 2023-07-26 15:56:55 +0300 |
---|---|---|
committer | Martin K. Petersen <martin.petersen@oracle.com> | 2023-08-08 04:34:08 +0300 |
commit | dd64f80587190265ca8a0f4be6c64c2fda6d3ac2 (patch) | |
tree | c76b971dda3ac702bf314be9e318abe7142ec8a2 /LICENSES | |
parent | 8eebf0e84f0614cebc7347f7bbccba4056d77d42 (diff) | |
download | linux-dd64f80587190265ca8a0f4be6c64c2fda6d3ac2.tar.xz |
scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock
As &qedi_percpu->p_work_lock is acquired by hard IRQ qedi_msix_handler(),
other acquisitions of the same lock under process context should disable
IRQ, otherwise deadlock could happen if the IRQ preempts the execution
while the lock is held in process context on the same CPU.
qedi_cpu_offline() is one such function which acquires the lock in process
context.
[Deadlock Scenario]
qedi_cpu_offline()
->spin_lock(&p->p_work_lock)
<irq>
->qedi_msix_handler()
->edi_process_completions()
->spin_lock_irqsave(&p->p_work_lock, flags); (deadlock here)
This flaw was found by an experimental static analysis tool I am developing
for IRQ-related deadlocks.
The tentative patch fix the potential deadlock by spin_lock_irqsave()
under process context.
Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Link: https://lore.kernel.org/r/20230726125655.4197-1-dg573847474@gmail.com
Acked-by: Manish Rangankar <mrangankar@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'LICENSES')
0 files changed, 0 insertions, 0 deletions