[PATCH v2] nvme: stop using AWUPF

Nilay Shroff nilay at linux.ibm.com
Wed Jan 28 01:35:36 PST 2026



On 1/28/26 1:56 PM, John Garry wrote:
> As described at [0], much of the atomic write parts of the specification
> are lacking.
> 
> For now, there is nothing which we can do in software about the lack of
> a dedicated NVMe write atomic command.
> 
> As for reading the atomic write limits, it is felt that the per-namespace
> values are mostly properly specified and it is assumed that they are
> properly implemented.
> 
> The specification of NAWUPF is quite clear. However the specification of
> NABSPF is less clear. The lack of clarity in NABSPF comes from deciding
> whether NABSPF applies when NSABP is 0 - it is assumed that NSABPF does
> not apply when NSABP is 0.
> 
> As for the per-controller AWUPF, how this value applies to shared
> namespaces is missing in the specification. Furthermore, the value is in
> terms of logical blocks, which is an NS entity.
> 
> Since AWUPF is so poorly defined, stop using it already together.
> Hopefully this will force vendors to implement NAWUPF support always.
> 
> Note that AWUPF not only effects atomic write support, but also the
> physical block size reported for the device.
> 
> To help users know this restriction, log an info message per NS.
> 
> [0] https://lore.kernel.org/linux-nvme/20250707141834.GA30198@lst.de/
> 
> Signed-off-by: John Garry <john.g.garry at oracle.com>
> ---

Looks good to me. 

Tested this patch on NVMe device reporting non-zero NAWUPF (and zero
AWUPF), as well as on device reporting non-zero AWUPF. In both cases,
the patch works as expected.

Tested-by: Nilay Shroff <nilay at linux.ibm.com>
Reviewed-by: Nilay Shroff <nilay at linux.ibm.com>



More information about the Linux-nvme mailing list