All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mohamed Khalfella <mkhalfella@purestorage.com>
To: Randy Jennings <randyj@purestorage.com>
Cc: Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] nvme: remove stale namespaces by NSID range during scan
Date: Tue, 25 Aug 2026 09:46:56 -0700	[thread overview]
Message-ID: <20260825164656.GF323015-mkhalfella@purestorage.com> (raw)
In-Reply-To: <CAPpK+O0e5HhDHEnu6uUw5AgtJfFoXjCmB2Q+13QDz1HtSdgDUQ@mail.gmail.com>

On Mon 2026-08-24 17:21:26 -0700, Randy Jennings wrote:
> On Sat, Aug 22, 2026 at 5:47 PM Mohamed Khalfella
> <mkhalfella@purestorage.com> wrote:
> >
> > nvme_scan_ns_list() drops the stale namespaces in each gap in the
> > reported NSID list one NSID at a time. Every iteration calls
> > nvme_find_get_ns() to look the namespace up and removes it if it is
> > present. The loop runs once per NSID in the gap rather than once per
> > namespace actually present.
> >
> > NSIDs are 32-bit, so a target with a sparse NSID space can make a
> > single gap spin the loop billions of times with nothing to remove.
> >
> >   watchdog: BUG: soft lockup - CPU#4 stuck for 26s!
> >   Workqueue: nvme-wq nvme_scan_work [nvme_core]
> >   RIP: 0010:__srcu_read_unlock+0xb/0x20
> >   Call Trace:
> >    nvme_find_get_ns+0x7d/0xb0 [nvme_core]
> >    nvme_scan_ns_list+0xe8/0x280 [nvme_core]
> >    nvme_scan_work+0x18a/0x280 [nvme_core]
> >    process_one_work+0x197/0x380
> >    worker_thread+0x2fe/0x410
> >    kthread+0xe0/0x100
> >
> > Rename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range()
> > and give it an open (start, end) NSID range. ctrl->namespaces is
> > sorted by NSID, so the whole gap is dropped in a single walk that
> > stops once end is reached. This bounds the work by the namespaces
> > that are present instead of by the size of the gap.
> >
> > Fixes: 540c801c65eb ("NVMe: Implement namespace list scanning")
> > Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com>
> > Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
> Reviewed-by: Randy Jennings <randyj@purestorage.com>
> 
> > ---
> >  drivers/nvme/host/core.c | 18 +++++++++---------
> 
> > -static void nvme_remove_invalid_namespaces(struct nvme_ctrl *ctrl,
> > -                                       unsigned nsid)
> > +static void nvme_remove_nsid_range(struct nvme_ctrl *ctrl, u32 start, u32 end)
> It is not intuitive to me that start is non-inclusive.  May we add
> a comment to that effect?

Yes, it is not intuitive. [start, end) makes more sense IMO. That is
said, this is how nvme_remove_invalid_namespaces() worked and I decided
not to change that because it is not part of the fix. I do not think a
comment will make a big difference here. The next person who works on
this code will read the nvme_remove_nsid_range(), it is a short
function, and figure out how it works.

> 
> >  {
> >         struct nvme_ns *ns, *next;
> >         LIST_HEAD(rm_list);
> >
> >         mutex_lock(&ctrl->namespaces_lock);
> >         list_for_each_entry_safe(ns, next, &ctrl->namespaces, list) {
> > -               if (ns->head->ns_id > nsid) {
> > +               if (ns->head->ns_id >= end)
> > +                       break;
> > +               if (ns->head->ns_id > start) {
> >                         list_del_rcu(&ns->list);


  reply	other threads:[~2026-08-25 16:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-23  0:46 [PATCH v2] nvme: remove stale namespaces by NSID range during scan Mohamed Khalfella
2026-08-25  0:21 ` Randy Jennings
2026-08-25 16:46   ` Mohamed Khalfella [this message]
2026-08-25  0:55 ` 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=20260825164656.GF323015-mkhalfella@purestorage.com \
    --to=mkhalfella@purestorage.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=randyj@purestorage.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.