]> 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>
Tue, 19 Sep 2023 10:22:29 +0000 (12:22 +0200)
commitac93def0dbb4b2b45aa3514d18f9e80b7928e65a
treed2412f5be0e0ed946ac114ef6b798dfc79c34cc1
parentbef6c89a92d025f92b298dd86b20ea99f7b34561
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