Re: [PATCH 00/38] lockd: Convert NLMv3 server-side procedures to xdrgen

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

On Thu, May 14, 2026, at 12:52 PM, Jeff Layton wrote:

> I got a sketchy review from Gemini that I had Claude validate that
> looks valid. You may want to add the memset() it recommends:
>
> --------------8<---------------
>
>   Analysis complete. The previous review (against b201ce7af2a2
> FREE_ALL) identified the right underlying bug but attributed it to the
> wrong commit. Here's the corrected analysis:
>
>   Correct commit: 3de744ee4e45 — "lockd: Use xdrgen XDR functions for
> the NLMv4 TEST procedure"
>
>   The regression: nlm4svc_lookup_file() (introduced in this commit)
> copies only fh.len bytes of the file handle without zeroing the
> remainder. Combined with .pc_argzero = 0 removing the
>   defensive memset of the argument buffer, bytes beyond fh.len in lock-
>>fh.data contain stale data from previous RPC calls. file_hash() in
> fs/lockd/svcsubs.c reads a fixed 32 bytes (NFS2_FHSIZE)
>    regardless of actual handle length, so for handles shorter than 32
> bytes the hash is non-deterministic — the same file handle can hash to
> different buckets on different calls, causing lock
>   state lookup failures.

This appears to be a regression introduced by the (previous) NLMv4
series, and does not affect the current NLMv3 xdrgen conversion.

I can post a fix for this later today. Note that memset() was
removed as part of the xdrgen conversion because it zeroes much
more memory than actually needs to be initialized.


-- 
Chuck Lever