From nobody Fri Oct 3 10:11:13 2025 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 76919283153 for ; Tue, 2 Sep 2025 10:22:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756808540; cv=none; b=Fl8YVl7eVUwuOoZ287d859Acll4U2uPBcuF3xzGQB/Xm4eBAQj0wT+LTgvoy0S+BqYP9A+sVSg1nB+2JLle+OGsG8+s4K1VxuTHFWALHMJjaGMaG2s7hjeHhwGRSnGyl+jqdonLKaEA7ymC7UpSEu6C/+gBLMMPYV89S1qt7y+c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756808540; c=relaxed/simple; bh=23+HyEDvJPuMTky4frK7z7kUWGJ8ShH0e5QwVpPLHxU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Mr2Hcq8xbQf+FwzcmsR1XGI2n9T7DSmJAx0y07rBCJeFeumJwcz93IH23odbU1I8aMm8tFEiasWAwwnu3a8A5nUV7b1O3Mri13qu+rOuiBgspFg4cBSNzaHo1qDlPY4gyE6LyJJ+4GeVRbJGt+VxgLLfFYMI+xqG8QnfJM9lIGY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KAWdjbgD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KAWdjbgD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1245C4CEF5; Tue, 2 Sep 2025 10:22:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756808540; bh=23+HyEDvJPuMTky4frK7z7kUWGJ8ShH0e5QwVpPLHxU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=KAWdjbgDwUmWxFYDA7w+TE7bZT8gCy/8cIT0s3UOo5bKo6fMYu5u0FrOBK5zF+e0L KV4M1EAg+T6Paab5+m2SgFX1G0y2y9dtXLcbmoaYNSOf5ujeVrIrb52+gXF8qAyjNO +RtxBNVqWqj29fv44wo8RkacfsxV7AitgEOR1UhRrDDEDSe7tNlVrVnguA/woTT1Sh PSJ9fwIx6WIzs8w58Ye0NPM3HlrNEh+CtqO4+axDl0Z0RG/EHqXEYamaLMW6qNPw+K rRtG0xaVTVkF2R2F8vk/yEYxurmFuEgWYz1QUOMReWIdr+aq4GeGI3aLUwwsZAp1ts ySf4PPAG2Q6pA== From: Daniel Wagner Date: Tue, 02 Sep 2025 12:22:00 +0200 Subject: [PATCH v3 1/4] nvmet-fc: move lsop put work to nvmet_fc_ls_req_op Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250902-fix-nvmet-fc-v3-1-1ae1ecb798d8@kernel.org> References: <20250902-fix-nvmet-fc-v3-0-1ae1ecb798d8@kernel.org> In-Reply-To: <20250902-fix-nvmet-fc-v3-0-1ae1ecb798d8@kernel.org> To: James Smart , Christoph Hellwig , Sagi Grimberg , Keith Busch Cc: Yi Zhang , Shinichiro Kawasaki , Hannes Reinecke , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Daniel Wagner X-Mailer: b4 0.14.2 It=E2=80=99s possible for more than one async command to be in flight from __nvmet_fc_send_ls_req. For each command, a tgtport reference is taken. In the current code, only one put work item is queued at a time, which results in a leaked reference. To fix this, move the work item to the nvmet_fc_ls_req_op struct, which already tracks all resources related to the command. Fixes: 710c69dbaccd ("nvmet-fc: avoid deadlock on delete association path") Reviewed-by: Hannes Reinecke Signed-off-by: Daniel Wagner --- drivers/nvme/target/fc.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/nvme/target/fc.c b/drivers/nvme/target/fc.c index a9b18c051f5bd830a6ae45ff0f4892c3f28c8608..6725c34dd7c90ae38f8271368e6= 09fd0ba267561 100644 --- a/drivers/nvme/target/fc.c +++ b/drivers/nvme/target/fc.c @@ -54,6 +54,8 @@ struct nvmet_fc_ls_req_op { /* for an LS RQST XMT */ int ls_error; struct list_head lsreq_list; /* tgtport->ls_req_list */ bool req_queued; + + struct work_struct put_work; }; =20 =20 @@ -111,8 +113,6 @@ struct nvmet_fc_tgtport { struct nvmet_fc_port_entry *pe; struct kref ref; u32 max_sg_cnt; - - struct work_struct put_work; }; =20 struct nvmet_fc_port_entry { @@ -235,12 +235,13 @@ static int nvmet_fc_tgt_a_get(struct nvmet_fc_tgt_ass= oc *assoc); static void nvmet_fc_tgt_q_put(struct nvmet_fc_tgt_queue *queue); static int nvmet_fc_tgt_q_get(struct nvmet_fc_tgt_queue *queue); static void nvmet_fc_tgtport_put(struct nvmet_fc_tgtport *tgtport); -static void nvmet_fc_put_tgtport_work(struct work_struct *work) +static void nvmet_fc_put_lsop_work(struct work_struct *work) { - struct nvmet_fc_tgtport *tgtport =3D - container_of(work, struct nvmet_fc_tgtport, put_work); + struct nvmet_fc_ls_req_op *lsop =3D + container_of(work, struct nvmet_fc_ls_req_op, put_work); =20 - nvmet_fc_tgtport_put(tgtport); + nvmet_fc_tgtport_put(lsop->tgtport); + kfree(lsop); } static int nvmet_fc_tgtport_get(struct nvmet_fc_tgtport *tgtport); static void nvmet_fc_handle_fcp_rqst(struct nvmet_fc_tgtport *tgtport, @@ -367,7 +368,7 @@ __nvmet_fc_finish_ls_req(struct nvmet_fc_ls_req_op *lso= p) DMA_BIDIRECTIONAL); =20 out_putwork: - queue_work(nvmet_wq, &tgtport->put_work); + queue_work(nvmet_wq, &lsop->put_work); } =20 static int @@ -388,6 +389,7 @@ __nvmet_fc_send_ls_req(struct nvmet_fc_tgtport *tgtport, lsreq->done =3D done; lsop->req_queued =3D false; INIT_LIST_HEAD(&lsop->lsreq_list); + INIT_WORK(&lsop->put_work, nvmet_fc_put_lsop_work); =20 lsreq->rqstdma =3D fc_dma_map_single(tgtport->dev, lsreq->rqstaddr, lsreq->rqstlen + lsreq->rsplen, @@ -447,8 +449,6 @@ nvmet_fc_disconnect_assoc_done(struct nvmefc_ls_req *ls= req, int status) __nvmet_fc_finish_ls_req(lsop); =20 /* fc-nvme target doesn't care about success or failure of cmd */ - - kfree(lsop); } =20 /* @@ -1410,7 +1410,6 @@ nvmet_fc_register_targetport(struct nvmet_fc_port_inf= o *pinfo, kref_init(&newrec->ref); ida_init(&newrec->assoc_cnt); newrec->max_sg_cnt =3D template->max_sgl_segments; - INIT_WORK(&newrec->put_work, nvmet_fc_put_tgtport_work); =20 ret =3D nvmet_fc_alloc_ls_iodlist(newrec); if (ret) { --=20 2.51.0 From nobody Fri Oct 3 10:11:13 2025 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 0DF5A283FC4 for ; Tue, 2 Sep 2025 10:22:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756808543; cv=none; b=ZkF8FfuNTKPY9liyCGUXRvniMgW6d72K48+Uo/+1e3QrKN+TgtJKY69COK2JviqqUAnfzjrlOynPBl8T6NM1q5IzpdM4kvoXpY2qKNkElAm2pcrMtsBU6J+KqD/PkRDcF18RpDChPFYK5Igu5Z2zMOmuY6ud++pMAqSO/BAcU2s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756808543; c=relaxed/simple; bh=pExNi9+edZehDdqmuJ6i1lZki0E/5kjYkaDbpM/DJjM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=fntkUgSR4ozXvHKc9exlcYDey9uPeufxvIn3shE0QaELB0LrwRlOjpXIcSqggTsMrw43NZl8NgPAfp6IAHvql3wdwO+CJzvs7/uThgigkotpRXAx/GP6n9alV4KgOHP7peLybz/X0cYOgzUJ9EGwvzGyBNpcWT9cVlTG67Kj/mA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LLlZYqdU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LLlZYqdU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3ECBDC4CEF5; Tue, 2 Sep 2025 10:22:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756808542; bh=pExNi9+edZehDdqmuJ6i1lZki0E/5kjYkaDbpM/DJjM=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=LLlZYqdU3KevwmEYeq6IAuWJMuVjLgmlYSDvY8XcXlg5uESCn2/2XSr3OcrWbOshx NYEoGFa93Yz2tQS9HvcUKkw0uXX0FPG7Hjnd1tUscJkRtmXqtr0omOEjQw3DDvIKgq dly3pWhOgx+ltIbnFLBl3SPtTT7TnYX2y3QDQqhTen1CkXFs4eMQQGqynbPmmPL1hn Hv2O6EUlvAbkOgG4uCy04bsbXwK9fB8iNcg8aHBnkFuCPknvTxu+Od59fLz3Lkx6AD QafS3M3rVgydFCI839AOxoUcVfYrdS4cn4wGBSAqELl2oitWIa4+7Kq1aEfew6HWBm Tes6f5rhbm3LQ== From: Daniel Wagner Date: Tue, 02 Sep 2025 12:22:01 +0200 Subject: [PATCH v3 2/4] nvmet-fc: avoid scheduling association deletion twice Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250902-fix-nvmet-fc-v3-2-1ae1ecb798d8@kernel.org> References: <20250902-fix-nvmet-fc-v3-0-1ae1ecb798d8@kernel.org> In-Reply-To: <20250902-fix-nvmet-fc-v3-0-1ae1ecb798d8@kernel.org> To: James Smart , Christoph Hellwig , Sagi Grimberg , Keith Busch Cc: Yi Zhang , Shinichiro Kawasaki , Hannes Reinecke , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Daniel Wagner X-Mailer: b4 0.14.2 When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion. Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted. Reported-by: Shinichiro Kawasaki Closes: https://lore.kernel.org/all/rsdinhafrtlguauhesmrrzkybpnvwantwmyfq2i= h5aregghax5@mhr7v3eryci3/ Reviewed-by: Hannes Reinecke Signed-off-by: Daniel Wagner --- drivers/nvme/target/fc.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/nvme/target/fc.c b/drivers/nvme/target/fc.c index 6725c34dd7c90ae38f8271368e609fd0ba267561..7d84527d5a43efe1d43ccf5fb80= 10a4884f99e3e 100644 --- a/drivers/nvme/target/fc.c +++ b/drivers/nvme/target/fc.c @@ -1075,6 +1075,14 @@ nvmet_fc_delete_assoc_work(struct work_struct *work) static void nvmet_fc_schedule_delete_assoc(struct nvmet_fc_tgt_assoc *assoc) { + int terminating; + + terminating =3D atomic_xchg(&assoc->terminating, 1); + + /* if already terminating, do nothing */ + if (terminating) + return; + nvmet_fc_tgtport_get(assoc->tgtport); if (!queue_work(nvmet_wq, &assoc->del_work)) nvmet_fc_tgtport_put(assoc->tgtport); @@ -1202,13 +1210,7 @@ nvmet_fc_delete_target_assoc(struct nvmet_fc_tgt_ass= oc *assoc) { struct nvmet_fc_tgtport *tgtport =3D assoc->tgtport; unsigned long flags; - int i, terminating; - - terminating =3D atomic_xchg(&assoc->terminating, 1); - - /* if already terminating, do nothing */ - if (terminating) - return; + int i; =20 spin_lock_irqsave(&tgtport->lock, flags); list_del_rcu(&assoc->a_list); --=20 2.51.0 From nobody Fri Oct 3 10:11:13 2025 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 4935528134C for ; Tue, 2 Sep 2025 10:22:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756808545; cv=none; b=NxOhgHqJhVl9/Tea+HR+aYoryPmRrrbqMsYrvNqNcH9kZXsqhsn6xh5C2zFcu2cDMQc3C5xH8VGSnBSziH5WyvDkmfa/DgejA8WiLrUCRn3kkMFnCTynVtFMM37CWmpUf36usXPFKqftbMFJpkasujSH5r7m88IhgBTOUPJOaK8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756808545; c=relaxed/simple; bh=XdaLPKat6GDbBRPcO/Jf/i/b/c+Fok3IBE+4J5oQnYA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=PtNDgGhw/POiDUqfDNLtGexCgJNZzUV2ffnoYnyGOZylH6uRg1cbEiEbVAuqpFREJigX3NBsEWhBtihT3WHAzOXwBLGjsH9/MR3Gu0sL/PUQCjSE2MdPS1uGIlZ7JKD+Ohokg52a4Wtp3UiiJT3DPdNNYTQQarSu7cUdoAPW19U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=d7BLtbSm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="d7BLtbSm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8697C4CEED; Tue, 2 Sep 2025 10:22:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756808545; bh=XdaLPKat6GDbBRPcO/Jf/i/b/c+Fok3IBE+4J5oQnYA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=d7BLtbSmF14hRfoeGMjdBAt9LFyXVNfLVyv0PN8J6acm1NrMFGjxJxyzZRVqfkPS4 TrCDmBDnfdJ5Ub2mcVKceJKFcivcKg2tyh2nMznlPN7VmJoXLSQ0cGtjQJhoqUCDle YWqROghliDxD+WCwea1io6nTpy4iuXMo3RBLxBHv9j616/koUrvpIggV0WkFSG2Jvo sc3XcnpX5TEjkjadv9FMNJre+0MBy6FOouiyrf4UMfd1eY05j/+XdjpvWvRVIGoTtC MDiBbT2uCtg0dMRST/XoEy7Of/+KpnCZGIStKT/7cZVfLPExF/zV6qJpRgp5GFpdze zDQNU80Ez9KiA== From: Daniel Wagner Date: Tue, 02 Sep 2025 12:22:02 +0200 Subject: [PATCH v3 3/4] nvmet-fcloop: call done callback even when remote port is gone Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250902-fix-nvmet-fc-v3-3-1ae1ecb798d8@kernel.org> References: <20250902-fix-nvmet-fc-v3-0-1ae1ecb798d8@kernel.org> In-Reply-To: <20250902-fix-nvmet-fc-v3-0-1ae1ecb798d8@kernel.org> To: James Smart , Christoph Hellwig , Sagi Grimberg , Keith Busch Cc: Yi Zhang , Shinichiro Kawasaki , Hannes Reinecke , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Daniel Wagner X-Mailer: b4 0.14.2 When the target port is gone, it's not possible to access any of the request resources. The function should just silently drop the response. The comment is misleading in this regard. Though it's still necessary to call the driver via the ->done callback so the driver is able to release all resources. Reported-by: Yi Zhang Closes: https://lore.kernel.org/all/CAHj4cs-OBA0WMt5f7R0dz+rR4HcEz19YLhnyGs= j-MRV3jWDsPg@mail.gmail.com/ Fixes: 84eedced1c5b ("nvmet-fcloop: drop response if targetport is gone") Reviewed-by: Hannes Reinecke Signed-off-by: Daniel Wagner --- drivers/nvme/target/fcloop.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/target/fcloop.c b/drivers/nvme/target/fcloop.c index 257b497d515a892a39da82d2f96b3fa3c6e10cdd..5dffcc5becae86c79ef75a12364= 7566b2dfc21f6 100644 --- a/drivers/nvme/target/fcloop.c +++ b/drivers/nvme/target/fcloop.c @@ -496,13 +496,15 @@ fcloop_t2h_xmt_ls_rsp(struct nvme_fc_local_port *loca= lport, if (!targetport) { /* * The target port is gone. The target doesn't expect any - * response anymore and the ->done call is not valid - * because the resources have been freed by - * nvmet_fc_free_pending_reqs. + * response anymore and thus lsreq can't be accessed anymore. * * We end up here from delete association exchange: * nvmet_fc_xmt_disconnect_assoc sends an async request. + * + * Return success because this is what LLDDs do; silently + * drop the response. */ + lsrsp->done(lsrsp); kmem_cache_free(lsreq_cache, tls_req); return 0; } --=20 2.51.0 From nobody Fri Oct 3 10:11:13 2025 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 3D0E42F3C01 for ; Tue, 2 Sep 2025 10:22:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756808548; cv=none; b=tvDmdhpNufaMDkoKEMXYId2G93A/s9IJMll28UTZ7xn1VZM52YsMrhMyS6r7AEk52fkV4VICs8DUTAWaEp0HU6BjQbvr7X74WF2ZCEGzGMXpbnkSIrl1pK1WqLfdpVI6oo/diy8ks7tdS/acz41AuE/FotO8eQ9vlWvuxrDNCJQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756808548; c=relaxed/simple; bh=gts/rTiszRszSd+E8YgjDWY8uUXdozvHeqnApxB8p4o=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=RzJJbg9+uM1me5U4lRS0cDMey1uMUiY0z+uhYoPd/3ZmWCczG80wbDTluAOWcqd9y07uhSoM5ijdaOH+CDSU5WL2dJjS2zzc8Z7aAB3tWDB2ljcEQmXnym0Kda848ujHuJIMy8gTwje8aFMsj9KhTtNUoaTHfhxR/Kkidjkj7No= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=li/lAITQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="li/lAITQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 60ADAC4CEF7; Tue, 2 Sep 2025 10:22:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756808547; bh=gts/rTiszRszSd+E8YgjDWY8uUXdozvHeqnApxB8p4o=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=li/lAITQwCvoPOw+bowFCpbpMsWY0CiLhLPc4GXDdDgSbItyBfFlWT06CnsVcrOUT hOsO3X3V8ksejEvjlBTy6Mu5XWEosfQVW6f/d8bYuRprbuj7CFowzk9kA2Uh+WUCjC zA8/2oKThxApz1iQbDKb4qyTY9BmA3xQp7YpRT2uJDOV2lbdUjWVWcT5Otc4sPVegV dNBaf0LQcox7s4dGawma0FuXOjXKzk/Cb80Uc9VFRqNZOWppLE9oHN/VLJMQLVJ1u2 y/RGf9fPJxxm9yoaSSE9Sga3ao8Du3p3VD3i6u94L9NVz4pJwhfDNEdQtv8ZZ9ThPh uFoRngpmL5Ztg== From: Daniel Wagner Date: Tue, 02 Sep 2025 12:22:03 +0200 Subject: [PATCH v3 4/4] nvme-fc: use lock accessing port_state and rport state Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250902-fix-nvmet-fc-v3-4-1ae1ecb798d8@kernel.org> References: <20250902-fix-nvmet-fc-v3-0-1ae1ecb798d8@kernel.org> In-Reply-To: <20250902-fix-nvmet-fc-v3-0-1ae1ecb798d8@kernel.org> To: James Smart , Christoph Hellwig , Sagi Grimberg , Keith Busch Cc: Yi Zhang , Shinichiro Kawasaki , Hannes Reinecke , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Daniel Wagner X-Mailer: b4 0.14.2 nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport. Reported-by: Shinichiro Kawasaki Closes: https://lore.kernel.org/all/u4ttvhnn7lark5w3sgrbuy2rxupcvosp4qmvj46= nwzgeo5ausc@uyrkdls2muwx Signed-off-by: Daniel Wagner Reviewed-by: Hannes Reinecke --- drivers/nvme/host/fc.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c index 3e12d4683ac72f9ef9c6dff64d22d5d97e6f3d60..03987f497a5b55533ee169c9a7c= b9b479d0f2d92 100644 --- a/drivers/nvme/host/fc.c +++ b/drivers/nvme/host/fc.c @@ -3032,11 +3032,17 @@ nvme_fc_create_association(struct nvme_fc_ctrl *ctr= l) =20 ++ctrl->ctrl.nr_reconnects; =20 - if (ctrl->rport->remoteport.port_state !=3D FC_OBJSTATE_ONLINE) + spin_lock_irqsave(&ctrl->rport->lock, flags); + if (ctrl->rport->remoteport.port_state !=3D FC_OBJSTATE_ONLINE) { + spin_unlock_irqrestore(&ctrl->rport->lock, flags); return -ENODEV; + } =20 - if (nvme_fc_ctlr_active_on_rport(ctrl)) + if (nvme_fc_ctlr_active_on_rport(ctrl)) { + spin_unlock_irqrestore(&ctrl->rport->lock, flags); return -ENOTUNIQ; + } + spin_unlock_irqrestore(&ctrl->rport->lock, flags); =20 dev_info(ctrl->ctrl.device, "NVME-FC{%d}: create association : host wwpn 0x%016llx " --=20 2.51.0