[PATCH RFC 1/2] nvme: downgrade WARN in nvme_setup_rw to pr_debug

[Chao S]

On Thu, May 07, 2026 at 07:48:09AM +0200, Christoph Hellwig wrote:
> What is "semantic mutation of Identify Namespace responses" [...]

The emulated controller returns a mutated Identify Namespace on
rescan (flbas META_EXT, lbaf.ms != 0, dps == 0) -- the host-unaware
geometry change Keith described (out-of-band format on a shared
namespace, or a non-compliant device), learned via rescan/AEN, not
the host's own Format NVM.

> [...] rather theoretical case [...]

Agreed v1 was wrong (1/2 hid the signal, 2/2 unrelated; 2/2 dropped).
Not fuzzer-only though: the out-of-band-format path Keith acknowledged
is real, and the branch is reachable from device data, so under
panic_on_warn this is a device-triggerable panic.  The deeper fencing
fix is the bigger TP-level work; v2 does not attempt it -- it only
adds the missing nvme_setup_rw() case for an unusable (metadata, no
PI, no profile) namespace whose I/O is already rejected, replacing the
assertion with one dev_warn_once().  Worth the bigger fix, or leave it
documented?

Thanks,
Chao

On Thu, May 7, 2026 at 1:48 AM Christoph Hellwig <hch at lst.de> wrote:
>
> On Sun, Apr 26, 2026 at 08:34:56PM -0400, Chao Shi wrote:
> > When an NVMe namespace is configured with embedded metadata (flbas bit 4
> > set, NVME_NS_FLBAS_META_EXT) but no Protection Information (dps=0) and
> > no NVME_NS_METADATA_SUPPORTED, nvme_setup_rw() fires WARN_ON_ONCE on
> > any request that reaches it with REQ_INTEGRITY unset.  The WARN was
> > observed repeatedly during NVMe fuzz testing with a FEMU-based fuzzer
> > that performs semantic mutation of Identify Namespace responses.
>
> What is "semantic mutation of Identify Namespace responses" supposed to
> mean?
>
> > In both cases the bio was submitted without REQ_INTEGRITY (because
> > blk_get_integrity() returned NULL at dispatch time, so
> > bio_integrity_action() returned 0 and bio_integrity_prep() was not
> > called), and it reaches nvme_setup_rw() for a namespace where
> > head->ms != 0.  The existing BLK_STS_NOTSUPP return correctly handles
> > this dispatch; the WARN_ON_ONCE is a false positive.
>
> That means we fail to properaly freeze and quiesce the queue over
> updateѕm which has much worse results than just a WARN_ON.  So if we
> care about this rather theoretical case we'll need to fix that.
>