Re: [PATCH v6 12/12] NFSD: Remove DRC checksum and payload_misses stat

["Chuck Lever" <cel@kernel.org>]

On Wed, Sep 23, 2026, at 10:56 AM, Jeff Layton wrote:
> On Mon, 2026-09-21 at 09:22 -0400, Chuck Lever wrote:
>> nfsd_cache_csum() costs CPU on every non-idempotent request. It also
>> prevents the use of zero-copy RDMA receives for WRITE and SYMLINK
>> because the payload must be in the server's memory before the DRC
>> lookup can run.
>> 
>> Commit 01a7decf7593 ("nfsd: keep a checksum of the first 256 bytes
>> of request") added the checksum when a growing cache made XID
>> collisions easier to hit. It is the only guard against a reused
>> XID: two calls with the same procedure and equal-length arguments
>> match on every other key field.
>> 
>> Acknowledgment-based eviction retires a TCP or RDMA entry once the
>> transport confirms delivery and a later request from the same
>> connection visits its bucket. Three kinds of entry outlast that: the
>> entries a connection has issued since it last visited each bucket,
>> entries from a connection the client has since closed, which no
>> later request can evict because their transport is gone, and UDP
>> entries. Those wait out RC_EXPIRE. A collision needs the same XID
>> from the same address and port within that window. The Linux NFS
>> client's XIDs are sequential from a seed drawn with
>> get_random_u32(), so an XID recurs only after 2^32 calls, and a
>> rebooted client does not replay its previous sequence. A client that
>> restarts its sequence from a fixed value and rebinds its previous
>> source port within RC_EXPIRE is unguarded, but a client that repeats
>> a live XID cannot reliably match replies to its own calls anyway.
>> 
>> A call whose XID matches an entry sent on the same connection is
>> therefore a retransmit. TCP and RDMA deliver the queued reply or
>> drop the connection, so drop the call as though the entry were
>> still in progress rather than replaying it. A match from another
>> connection, or from UDP, is replayed as before.
>> 
>> Remove the checksum, the nfsd_drc_mismatch tracepoint, and the
>> payload_misses stat that counted checksum-detected collisions.
>> nfsd_dispatch() no longer snapshots the argument stream before
>> decoding, and with k_csum gone, struct nfsd_cacherep shrinks to 136
>> bytes.
>> 
>> The "payload misses" line disappears from
>> /proc/fs/nfsd/reply_cache_stats. No known userspace tool parses it.
>> 
>> Assisted-by: LLM
>> Signed-off-by: Chuck Lever <cel@kernel.org>

>> @@ -561,6 +492,13 @@ int nfsd_cache_lookup(struct svc_rqst *rqstp, unsigned int start,
>>  	if (rp->c_state == RC_INPROG)
>>  		goto out_trace;
>>  
>> +	/*
>> +	 * The connection that carried the reply delivers it, so a
>> +	 * retransmit on that connection needs no replay.
>> +	 */
>> +	if (rp->c_pos && rp->c_xprt == rqstp->rq_xprt->xpt_id)
>> +		goto out_trace;
>> +
>
> This patch seems to break pynfs RPLY14, which does a mkdir and then a
> replay of it later.

Note: The replay is on the same connection.


> The test is arguably broken though, since it does the replay over the
> same connection as the original request. I'm looking into fixing that
> (and will check for others that might be similarly problematic).

The new NFSD behavior is by design, suggested by Neil. Any client
that reuses an XID on the same connection is either broken or has
sent 4 billion requests in 120 seconds. Clients are supposed to
send retransmits on a different connection.

So, it's possible the test is wrong, but we need to think hard
about whether this new behavior will be a problem for existing
NFSv4.0 clients.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)