]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock
authorChengfeng Ye <dg573847474@gmail.com>
Wed, 26 Jul 2023 12:56:55 +0000 (12:56 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 23 Sep 2023 08:46:53 +0000 (10:46 +0200)
commite89ac572c3d554dbc04e70b91cbf2bbd1c5c984d
treed192a8c8fc33db1a208e0f8a13fe360eef9de078
parent15d988ddfccc2cb2a23102bdbbe79023238a3948
scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock

[ Upstream commit dd64f80587190265ca8a0f4be6c64c2fda6d3ac2 ]

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/scsi/qedi/qedi_main.c