Re: Questions Regarding Delegation Claim Behavior

[Chuck Lever <chuck.lever@oracle.com>]

On 5/27/25 8:58 AM, Chuck Lever wrote:
> On 5/26/25 7:10 AM, Petro Pavlov wrote:
>>
>> I believe the following section of the RFC may be relevant to the use of
>> a delegation |stateid| in relation to the file being accessed:
>>
>>     If the stateid type is not valid for the context in which the
>>     stateid appears, return NFS4ERR_BAD_STATEID. Note that a stateid may
>>     be valid in general, as would be reported by the TEST_STATEID
>>     operation, but be invalid for a particular operation, as, for
>>     example, when a stateid that doesn't represent byte-range locks is
>>     passed to the non-from_open case of LOCK or to LOCKU, or when a
>>     stateid that does not represent an open is passed to CLOSE or
>>     OPEN_DOWNGRADE. In such cases, the server MUST return
>>     NFS4ERR_BAD_STATEID.

For the record, this is the sixth bullet point in the final paragraph of
Section 8.2.4 of RFC 8881.

Perhaps this text is applicable, but I have trouble with a compliance
statement that mandates specific on-the-wire behavior but does not have
an exhaustive list of cases where it applies. Such statements are not
supposed to be so hand-wavy.

And in any event, I prefer NFS4ERR_INVAL in such cases, as the stateid
is clearly valid. BAD_STATEID will most likely trigger the client to
perform state recovery, which is almost certain to cause the client to
simply resend the same request after determining that no state recovery
is needed. Lather, rinse, repeat.

But, a pynfs test case or two here is a good thing. The client is
misbehaving, and our CI isn't looking for this corner case. I hope you
are permitted to contribute your test cases to upstream pynfs.


-- 
Chuck Lever