From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C24A030FA7 for ; Wed, 20 Sep 2023 12:26:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CB8AC433C8; Wed, 20 Sep 2023 12:26:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1695212761; bh=1hHVowjTFM4OmL2XiAbYIb2sSZXpNlvQ4RgGMuiZpIM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yRKQDPqyAP4SQVhEVHT26I2CE9UViC2oMY1hQTXavI20krZQTmNiLXpVKYveJKnWw DnNfDEhzTrlbSwFngUjO8b/BtTKxjqQ8fkw+R9t3jmH1vEM8DhPe8mOVgrMfCVa7UB Alx63SGwM9Dh23mAa4FD20m0IuS+z3bcNweEeM64= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Chengfeng Ye , Manish Rangankar , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 5.4 035/367] scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock Date: Wed, 20 Sep 2023 13:26:52 +0200 Message-ID: <20230920112859.418144230@linuxfoundation.org> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20230920112858.471730572@linuxfoundation.org> References: <20230920112858.471730572@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chengfeng Ye [ 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) ->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 Link: https://lore.kernel.org/r/20230726125655.4197-1-dg573847474@gmail.com Acked-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin --- drivers/scsi/qedi/qedi_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c index 92c4a367b7bd7..6b47921202eba 100644 --- a/drivers/scsi/qedi/qedi_main.c +++ b/drivers/scsi/qedi/qedi_main.c @@ -1910,8 +1910,9 @@ static int qedi_cpu_offline(unsigned int cpu) struct qedi_percpu_s *p = this_cpu_ptr(&qedi_percpu); struct qedi_work *work, *tmp; struct task_struct *thread; + unsigned long flags; - spin_lock_bh(&p->p_work_lock); + spin_lock_irqsave(&p->p_work_lock, flags); thread = p->iothread; p->iothread = NULL; @@ -1922,7 +1923,7 @@ static int qedi_cpu_offline(unsigned int cpu) kfree(work); } - spin_unlock_bh(&p->p_work_lock); + spin_unlock_irqrestore(&p->p_work_lock, flags); if (thread) kthread_stop(thread); return 0; -- 2.40.1