From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Nilay Shroff <nilay@linux.ibm.com>,
Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@meta.com>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 2/2] nvme: fix unmatched id's under delayed path deletion
Date: Fri, 27 Feb 2026 14:53:48 +0100 [thread overview]
Message-ID: <20260227135348.GA20751@lst.de> (raw)
In-Reply-To: <aaCSe6PZu-PiH72S@kbusch-mbp>
On Thu, Feb 26, 2026 at 11:35:39AM -0700, Keith Busch wrote:
> On Fri, Feb 27, 2026 at 12:01:48AM +0530, Nilay Shroff wrote:
> > On 2/26/26 10:21 PM, Keith Busch wrote:
> > > This is looking pretty tricky to resolve. The best solution I'm coming
> > > up with so far is to have the scan_work synthesize a
> > > NVME_AER_NOTICE_NS_CHANGED event for every controller in the subsystem,
> > > then re-kick their scan work if the scan_work removed anything.
> >
> > So does your disk when reuse NSID, changes ns ids such as NGUID/UUID/EUI64?
>
> Yes. The NSID is put back into the available pool when it's deleted, but
> the UID associated with it is newly generated upon creation.
Yeah, that is one of the two allowed nvme behaviors, and there's a bit
to detect if the persistent ids can be reused or not.
next prev parent reply other threads:[~2026-02-27 13:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 20:21 [PATCH 1/2] nvme-multipath: fix leak on try_module_get failure Keith Busch
2026-02-25 20:21 ` [PATCH 2/2] nvme: fix unmatched id's under delayed path deletion Keith Busch
2026-02-25 20:34 ` Keith Busch
2026-02-26 7:04 ` Nilay Shroff
2026-02-26 15:37 ` Christoph Hellwig
2026-02-26 16:51 ` Keith Busch
2026-02-26 18:31 ` Nilay Shroff
2026-02-26 18:35 ` Keith Busch
2026-02-27 13:53 ` Christoph Hellwig [this message]
2026-02-26 6:35 ` [PATCH 1/2] nvme-multipath: fix leak on try_module_get failure Nilay Shroff
2026-02-26 8:31 ` John Garry
2026-02-26 15:35 ` Christoph Hellwig
2026-04-15 9:26 ` John Garry
2026-04-15 14:23 ` Keith Busch
2026-04-15 15:13 ` John Garry
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=20260227135348.GA20751@lst.de \
--to=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
/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.