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
