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 1233C576EC3; Wed, 9 Sep 2026 14:07:16 +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=1788962837; cv=none; b=uecMipFGZnJdpzej14BN75ZdvBJ0cyI0C7TveoDGVytQ+iC8HyFDr42DN3cYKA31IzV9zfw51tzVlpVu1DNL55WVclRqE+JfA+L2h36xfp0fO2xOdb/O/ttrNC5Kpti4jHGbCxYeFVwooGY9f6tGbwA51ZOsYEBHYnSGQ+5ex2k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788962837; c=relaxed/simple; bh=6nhIUt9BIx2MN6mx6g+YTs3jUDsoStm41OOAPpcWR/s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kOYPRpybPi9oxC0mzYdUvFq0BZY+Pg5cfo55BIF7aMRNrYEmD1/FCm53MfhHrd+lXjtlmLD66Xn4JnMZ4cprrYrz6T2r/WUahaX2R+cTwW2DDGwdFYXb0ZKjq+1zc//YXjTAUoK1UveXJCcue+fwHfXaEmK1Y8/GB+46Ogv2yeQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=KIHysmzX; 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="KIHysmzX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 220F41F00A3D; Wed, 9 Sep 2026 14:07:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1788962835; bh=M+ymtVTH5rkZPQl3+3sZBiXrICXKoIk5/UKFw1uzdSk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=KIHysmzXWNkP5jXuJKPTniZyputdl+d9hrqw1W8slfXDNJz7+gx/ILtZx5CDgap7O DgI0SmRAezjUH2eLXkf82WbVmUDX9dN9D/FrZSOXpekD7D0ut4V+CnERpsM0Xw+Pvm Zh9/xk+VxYKiP7NA9+h+fyxXMMWTJTstyZPxJ3ec= 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 7.2 426/556] scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject Date: Wed, 9 Sep 2026 15:41:46 +0200 Message-ID: <20260909134245.585099451@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260909134230.441546314@linuxfoundation.org> References: <20260909134230.441546314@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 7.2-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); }