Re: [RFC PATCH] nvme: refuse an unsolicited format change on a namespace that is in use

On Tue, Aug 11, 2026 at 04:29:51PM -0400, Chris S wrote:
> On Tue, Aug 11, 2026 at 01:30:54PM -0600, Keith Busch wrote:
> > Refusing to acknowledge the new format doesn't mean you get to continue
> > using the old format. You're going to corrupt memory and data this way.
> 
> You're right - the teardown is the problem, not the refusal.
> 
> nvme_ns_remove() never sets GD_DEAD, so del_gendisk() takes the
> non-surprise path and asks the filesystem to write back.  Those bios
> go through nvme_setup_rw() with the stale lba_shift.  set_capacity(0)
> doesn't catch them on a partition, which keeps its own bd_nr_sectors.
> 
> So it should mark the disk dead first and drop the cache instead:
> 
>         blk_mark_disk_dead(ns->disk);
>         ret = NVME_SC_INVALID_NS | NVME_STATUS_DNR;
> 
> Multipath needs more than that - the openers are on head->disk, and
> only the path gets removed.
> 
> Is that the direction, or is refuse-and-remove wrong here to begin
> with?

You need a nvme spec level change for this to work. There's nothing we
can do today to close every race where the driver attempts to use a
stale LBA shift when the format was changed externally.

What I proposed in the past was that the device has to return a new
error code for all new IO until the host queries the appropriate
Namespace identification to acknowledge the new LBA format. Kind of like
a SCSI "Check Condition Parameters Changed". An enlightend host could
trigger a queue freeze and namespace rescan after seeing this status,
clearing the device's latch and resume IO after setting up the new queue
limits.