Re: Issue with AWUPF when using multiple controllers in a subsystem

[John Garry <john.g.garry@oracle.com>]

On 10/04/2025 10:19, Christoph Hellwig wrote:
> On Thu, Apr 10, 2025 at 10:09:53AM +0100, John Garry wrote:
>> This, combined with no dedicated NVMe command to issue a write atomically
>> (which could error for out-of-limits size/crossing boundary), is pretty
>> concerning.
> 
> Agreed.  Given that Oracle is actually a major user of NVMe, can you
> bring that to the working group's attention?  That works much better
> than a random Linux maintainer.

Sure, I'll ask someone.

> 
>> As an aside, I found the scope of the boundary definition to be quite vague
>> as well.
> 
> It used to be really horrible, but got a major rework for multiple
> atomicy in NVMe 2.2 (or was it 2.1?). 

I am not really talking about multiple atomicy here, but something more 
basic...

> Which version did you check?

I am specifically referring to NSFEAT.NSABP, which is now described in 
NVM Command Set Specification 1.1.

I just found it odd that NSABP is related to boundary, but describes 
whether NAWUN et al fields are used or not (but not whether NABSPF is 
valid). Having said that, I'd think that NABSPF is always valid from 
2.1.4.4 Atomic Boundaries "The namespace supports Atomic Boundaries if
NABSN or NABSPF are set to non-zero values".

But from "Figure 4: Atomicity Parameters for Single Atomicity Mode", 
"Namespace Atomic Boundary Parameters" cell, it tells to refer to 
"Identify Namespace data structure" which describes NSFEAT.NSABP; 
however it does also describe NABSPF.

I am getting the feeling that the kernel driver should not check 
NSFEAT.NSABP on whether NABSPF is valid (which it does today).