public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chengfeng Ye <dg573847474@gmail.com>
To: james.smart@broadcom.com, dick.kennedy@broadcom.com,
	jejb@linux.ibm.com, martin.petersen@oracle.com,
	justin.tee@broadcom.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Chengfeng Ye <dg573847474@gmail.com>
Subject: [PATCH] scsi: lpfc: Fix potential deadlock on &phba->hbalock
Date: Wed, 26 Jul 2023 15:53:42 +0000	[thread overview]
Message-ID: <20230726155342.51623-1-dg573847474@gmail.com> (raw)

As &phba->hbalock is acquired by hardirq such as lpfc_sli_intr_handler(),
process context code acquiring the lock &phba->hbalock should disable
irq, otherwise deadlock could happen if the irq preempt the execution
while the lock is held in process context on the same CPU.

Most lock acquicision site disables irq but inside the callback
lpfc_cmpl_els_uvem() the lock is acquired without explicitly disable irq.
The outside caller of this callback also seems not disable irq.

[Deadlock Scenario]
lpfc_cmpl_els_uvem()
    -> spin_lock(&phba->hbalock)
        <irq>
        -> lpfc_sli_intr_handle()
        -> spin_lock(&phba->hbalock); (deadlock here)

This flaw was found by an experimental static analysis tool I am
developing for irq-related deadlock.

The patch fix the potential deadlock by spin_lock_irqsave() just like
other callsite.

Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
---
 drivers/scsi/lpfc/lpfc_els.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 2bad9954c355..9667b4937b3a 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -12398,6 +12398,7 @@ lpfc_cmpl_els_uvem(struct lpfc_hba *phba, struct lpfc_iocbq *icmdiocb,
 	u32 ulp_word4 = get_job_word4(phba, rspiocb);
 	struct lpfc_dmabuf *dmabuf = icmdiocb->cmd_dmabuf;
 	struct lpfc_vmid *vmid;
+	unsigned long flags;
 
 	vmid = vmid_context->vmp;
 	if (!ndlp || ndlp->nlp_state != NLP_STE_UNMAPPED_NODE)
@@ -12419,11 +12420,11 @@ lpfc_cmpl_els_uvem(struct lpfc_hba *phba, struct lpfc_iocbq *icmdiocb,
 				 ulp_status, ulp_word4);
 		goto out;
 	}
-	spin_lock(&phba->hbalock);
+	spin_lock_irqsave(&phba->hbalock, flags);
 	/* Set IN USE flag */
 	vport->vmid_flag |= LPFC_VMID_IN_USE;
 	phba->pport->vmid_flag |= LPFC_VMID_IN_USE;
-	spin_unlock(&phba->hbalock);
+	spin_unlock_irqrestore(&phba->hbalock, flags);
 
 	if (vmid_context->instantiated) {
 		write_lock(&vport->vmid_lock);
-- 
2.17.1


             reply	other threads:[~2023-07-26 15:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-26 15:53 Chengfeng Ye [this message]
2023-07-26 22:16 ` [PATCH] scsi: lpfc: Fix potential deadlock on &phba->hbalock Justin Tee
2023-07-27  5:40   ` Chengfeng Ye
2023-07-27 17:53     ` Justin Tee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230726155342.51623-1-dg573847474@gmail.com \
    --to=dg573847474@gmail.com \
    --cc=dick.kennedy@broadcom.com \
    --cc=james.smart@broadcom.com \
    --cc=jejb@linux.ibm.com \
    --cc=justin.tee@broadcom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox