From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 F3D6C566C5B; Wed, 9 Sep 2026 14:29:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788964169; cv=none; b=hfntcYUnoNtz4yfuzCg6h0UUlb2BC5VhMRp6h4wJNnr5cz3In30/JYtaRBKqQrOZfqy6/9UJmGSS36H3lyr19nRXCj1a3GSYoFSbuOUwbx9Bs1S3fnKRHs9WOZw/gFzfOBSGDMh6DNRjGw8HMuybpul7+vq84pXOdcVAF13zEI8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788964169; c=relaxed/simple; bh=8gqnHoi8mqUtJuivn8dJHFSryBeC6o0d4VDkc9yPC78=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SYnwxB/S8fiYyRjoT9KbfQFRw+JGqV6PkYtfWpQdIb4qbVt+rSuBboydY459RbaEC2VRol3mI/bcgbbh8gyzdgYMIqXcfLSkKqN6x1hkbFp/Jy0LEb6mJtZT3hpUALR9KtOWgNz4AMl4HMmv1Fpg5E7EbpVUoNH/51v9Ug4/MOE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=rGq5DwAr; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="rGq5DwAr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AF731F00A3A; Wed, 9 Sep 2026 14:29:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1788964167; bh=RSOfHxsRgtE8oKKyaKQsavoYnlBmsA5WHVh9UkPHOUQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=rGq5DwArUVqVWjWVGa+K6whIPG5CfcDWIfe69sJA7fBg8szL/sv1SzDJof652uMqD OncnFko+3cW4kgh00YHwhsqN0o9+W4YSfejS68rib1nzDOOnUa+x9S2Q4icqliDwgn um2QHNJxRiSx5/w9Skw1K01nMDEoCG6HGIoc+hOw= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Nilesh Javali , Hannes Reinecke , "Martin K. Petersen (Oracle)" Subject: [PATCH 6.18 331/583] scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject Date: Wed, 9 Sep 2026 15:40:16 +0200 Message-ID: <20260909134249.466053214@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260909134237.773280130@linuxfoundation.org> References: <20260909134237.773280130@linuxfoundation.org> User-Agent: quilt/0.69 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 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nilesh Javali commit f743488e4a203049f27ec5d8cd0caccc483af01e upstream. qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps. Fixes: 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe") Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260723050413.3897522-53-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/qla2xxx/qla_nvme.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/scsi/qla2xxx/qla_nvme.c +++ b/drivers/scsi/qla2xxx/qla_nvme.c @@ -374,6 +374,7 @@ static int qla_nvme_xmt_ls_rsp(struct nv srb_t *sp; int rval = QLA_FUNCTION_FAILED; uint8_t cnt = 0; + unsigned long flags; if (!fcport || fcport->deleted) goto out; @@ -440,7 +441,9 @@ out: a.vp_idx = vha->vp_idx; a.nport_handle = uctx->nport_handle; a.xchg_address = uctx->exchange_address; + spin_lock_irqsave(ha->base_qpair->qp_lock_ptr, flags); qla_nvme_ls_reject_iocb(vha, ha->base_qpair, &a, true); + spin_unlock_irqrestore(ha->base_qpair->qp_lock_ptr, flags); kfree(uctx); return rval; } @@ -1127,6 +1130,10 @@ static void qla_nvme_lsrjt_pt_iocb(struc lsrjt_iocb->rx_byte_count = 0; } +/* + * Allocates from and advances the request ring, so the caller must hold + * qp->qp_lock_ptr (the response-queue caller already holds it). + */ static int qla_nvme_ls_reject_iocb(struct scsi_qla_host *vha, struct qla_qpair *qp, struct qla_nvme_lsrjt_pt_arg *a, bool is_xchg_terminate) @@ -1183,6 +1190,7 @@ qla2xxx_process_purls_pkt(struct scsi_ql { struct qla_nvme_unsol_ctx *uctx = item->purls_context; struct qla_nvme_lsrjt_pt_arg a; + unsigned long flags; int ret = 1; #if (IS_ENABLED(CONFIG_NVME_FC)) @@ -1195,7 +1203,9 @@ qla2xxx_process_purls_pkt(struct scsi_ql a.vp_idx = vha->vp_idx; a.nport_handle = uctx->nport_handle; a.xchg_address = uctx->exchange_address; + spin_lock_irqsave(vha->hw->base_qpair->qp_lock_ptr, flags); qla_nvme_ls_reject_iocb(vha, vha->hw->base_qpair, &a, true); + spin_unlock_irqrestore(vha->hw->base_qpair->qp_lock_ptr, flags); list_del(&uctx->elem); kfree(uctx); }