Re: [PATCH v2 3/4] NFSD: Do not cache solo SEQUENCE operations

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

On 10/7/25 6:12 PM, NeilBrown wrote:
> On Wed, 08 Oct 2025, Chuck Lever wrote:
>> On 10/7/25 12:04 PM, Chuck Lever wrote:
>>>  RFC 8881 Section 2.10.6.1.3 says:
>>>
>>>> On a per-request basis, the requester can choose to direct the
>>>> replier to cache the reply to all operations after the first
>>>> operation (SEQUENCE or CB_SEQUENCE) via the sa_cachethis or
>>>> csa_cachethis fields of the arguments to SEQUENCE or CB_SEQUENCE.
>>> RFC 8881 Section 2.10.6.4 further says:
>>>
>>>> If sa_cachethis or csa_cachethis is TRUE, then the replier MUST
>>>> cache a reply except if an error is returned by the SEQUENCE or
>>>> CB_SEQUENCE operation (see Section 2.10.6.1.2).
>>> This suggests to me that the spec authors do not expect an NFSv4.1
>>> server implementation to ever cache the result of a SEQUENCE
>>> operation (except perhaps as part of a successful multi-operation
>>> COMPOUND).
>>>
>>> NFSD attempts to cache the result of solo SEQUENCE operations,
>>> however. This is because the protocol does not permit servers to
>>> respond to a SEQUENCE with NFS4ERR_RETRY_UNCACHED_REP. If the server
>>> always caches solo SEQUENCE operations, then it never has occasion
>>> to return that status code.
>>>
>>> However, clients use solo SEQUENCE to query the current status of a
>>> session slot. A cached reply will return stale information to the
>>> client, and could result in an infinite loop.
>>
>> The pynfs SEQ9f test is now failing with this change. This test:
>>
>> - Sends a CREATE_SESSION
>> - Sends a solo SEQUENCE with sa_cachethis set
>> - Sends the same operation without changing the slot sequence number
>>
>> The test expects the server's response to be NFS4_OK. NFSD now returns
>> NFS4ERR_SEQ_FALSE_RETRY instead.
>>
>> It's possible the test is wrong, but how should it be fixed?
>>
>> Is it compliant for an NFSv4.1 server to ignore sa_cachethis for a
>> COMPOUND containing a solo SEQUENCE?
>>
>> When reporting a retransmitted solo SEQUENCE, what is the correct status
>> code?
> 
> Interesting question....
> To help with context: you wrote:
> 
>    However, clients use solo SEQUENCE to query the current status of a
>    session slot.  A cached reply will return stale information to the
>    client, and could result in an infinite loop.
> 
> Could you please expand on that?  What in the reply might be stale, and
> how might that result in an infinite loop?
> 
> Could a reply to a replayed singleton SEQUENCE simple always return the
> current info, rather than cached info?

If a cached reply is returned to the client, the slot sequence number
doesn't change, and neither do the SEQ4_STATUS flags.

The only real recovery in this case is to destroy the session, which
will remove the cached reply.

We've determined that the Linux NFS client never asserts sa_cachethis
when sending a solo SEQUENCE, so the questions above might be academic.


-- 
Chuck Lever