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

[Keith Busch]

On Sat, May 16, 2026 at 11:53:54PM -0400, Chao S wrote:
> On Thu, May 07, 2026 at 07:12:26PM +0100, Keith Busch wrote:
> > [...] how that was defeated [...]
> 
> Hi Keith,
> 
> Not the freeze.  The WARN does not depend on q->limits, but on
> ns->head->ms (read live at dispatch, set inside the freeze window) and
> on REQ_INTEGRITY, never set for EXT_LBAS-non-PI.  capacity==0 only
> gates submission (bio_check_eod()), not dispatch: a writeback bio that
> passed bio_check_eod() under the old capacity sits on the task plug
> holding no q_usage_counter ref, so it does not block the freeze;
> blk_finish_plug() flushes it after the update committed head->ms != 0
> (dmesg: the capacity-change line prints before the WARN).
> 
> So it is reachable -- the host-unaware geometry change you described,
> unrelated to your block fix.  The deeper fencing gap is the separate
> TP-level issue; v2 does not attempt it, it only stops a
> device-reachable, already-safely-rejected dispatch from being a WARN
> (a panic under panic_on_warn).

I think tHe WARN is serving it's intendeded purpose: the block layer
shouldn't have submitted this request. You can't do generic read/write
with extended metadatate as the DMA is going to corrupt memory with
respect to what the block layer expects.

This driver is depending on the capacity constraint to prevent this
scenario, so I think The "end-of-device" check needs to happen within
the entered queue context. If there's a scenario that escapes that
check, then I think that's what needs fixing, not the driver.