From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
To: Nilay Shroff <nilay@linux.ibm.com>
Cc: hch@lst.de, kbusch@kernel.org, sagi@grimberg.me, kch@nvidia.com,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
gjoyce@linux.ibm.com
Subject: Re: [PATCH v2 1/2] nvmet: defer setting ns->enabled to false in nvmet_ns_disable()
Date: Thu, 1 Oct 2026 07:55:45 +0200 [thread overview]
Message-ID: <ar30Q5H1fuyFtDwM@shinmob> (raw)
In-Reply-To: <20260918162736.802665-2-nilay@linux.ibm.com>
On Sep 18, 2026 / 21:57, Nilay Shroff wrote:
> nvmet_ns_disable() currently clears ns->enabled before draining
> in-flight I/O references. This allows namespace configuration to be
> changed while existing I/O requests can still hold a reference to the
> namespace.
>
> This can race with configuration of namespace attributes such as the
> device path, UUID, NGUID etc. These attributes can be accessed by I/O
> requests without holding subsys->lock and must not be modified while
> such requests are still using the namespace.
>
> In nvmet_ns_disable(), keep ns->enabled set while existing namespace
> references are being drained, so namespace configuration remains blocked
> until all in-flight I/O has completed. Set ns->enabled to false only
> after the namespace references have been drained and the namespace
> device has been disabled.
>
> Introduce the NVMET_NS_IO_LIVE flag, which is set after the namespace
> is successfully enabled in nvmet_ns_enable(). When nvmet_ns_disable()
> starts, clear NVMET_NS_IO_LIVE so that the I/O path stops admitting new
> I/O once the flag is cleared. Using test_and_clear_bit() in
> nvmet_ns_disable() also prevents concurrent callers from starting a
> second disable operation.
>
> Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
Recent blktests-ci trial runs for nvme-7.3 branch reported failure of nvme/052
[*]. It is required to repeat the test case 3 to 20 times to recreate the
failure on my test system. I bisected and find this patch is the trigger of the
failure.
Nilay, may I ask you to take a look in the failure? I'm not sure if this should
be addressed in kernel side of blktests side.
[*]
nvme/052 (tr=loop) (Test file-ns creation/deletion under one subsystem) [failed]
runtime ... 12.165s
--- tests/nvme/052.out 2026-09-29 00:36:09.236884509 +0000
+++ /home/runner/blktests/results/nodev_tr_loop/nvme/052.out.bad 2026-09-29 01:06:09.513359622 +0000
@@ -1,2 +1,4 @@
Running nvme/052
+namespace with uuid "492157d2-1f3b-4bc2-b717-e6234d0fa466" not created within 5 seconds
+FAIL
Test complete
next prev parent reply other threads:[~2026-10-01 5:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 16:27 [PATCH v2 0/2] nvmet: fix subtle race in I/O processing and ns configuration Nilay Shroff
2026-09-18 16:27 ` [PATCH v2 1/2] nvmet: defer setting ns->enabled to false in nvmet_ns_disable() Nilay Shroff
2026-09-21 6:59 ` Christoph Hellwig
2026-10-01 5:55 ` Shin'ichiro Kawasaki [this message]
2026-10-01 11:42 ` Nilay Shroff
2026-10-02 3:20 ` Shin'ichiro Kawasaki
2026-09-18 16:27 ` [PATCH v2 2/2] nvmet: don't allow I/O admission after percpu ns reference is killed Nilay Shroff
2026-09-21 6:59 ` Christoph Hellwig
2026-09-22 14:59 ` [PATCH v2 0/2] nvmet: fix subtle race in I/O processing and ns configuration Keith Busch
2026-09-22 15:04 ` Keith Busch
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=ar30Q5H1fuyFtDwM@shinmob \
--to=shinichiro.kawasaki@wdc.com \
--cc=gjoyce@linux.ibm.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
--cc=sagi@grimberg.me \
/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
all inboxes | Powered by JetHome®