kernel/git/stable/linux.git/fs/lockd/lockd.h, branch linux-7.2.y

lockd: Avoid hashing uninitialized bytes in nlm4svc_lookup_file()

2026-06-09T20:32:59+00:00

file_hash() digests the first LOCKD_FH_HASH_SIZE bytes of nfs_fh.data when bucketing nlm_files[], independent of fh.size. Commit 3de744ee4e45 ("lockd: Use xdrgen XDR functions for the NLMv4 TEST procedure") set .pc_argzero to zero for the converted procedures and moved file-handle population into nlm4svc_lookup_file(), which copies only xdr_lock->fh.len bytes into lock->fh.data. When an NLMv4 client presents a file handle shorter than LOCKD_FH_HASH_SIZE, bytes fh.len..31 retain whatever the argument buffer held from an earlier request. The same wire handle then hashes to different buckets across calls; nlm_lookup_file() misses the existing nlm_file entry, and lock-state lookups fail. Zero only the tail bytes that file_hash() would otherwise consume. Handles of LOCKD_FH_HASH_SIZE or larger already populate every byte that file_hash() reads. Reported-by: Jeff Layton Closes: https://lore.kernel.org/r/5229a9746d723a3f830120c0b966510f75badfc2.camel@kernel.org Fixes: 3de744ee4e45 ("lockd: Use xdrgen XDR functions for the NLMv4 TEST procedure") Signed-off-by: Chuck Lever

lockd: Use xdrgen XDR functions for the NLMv3 TEST procedure

2026-06-09T20:32:59+00:00

The NLM TEST procedure requires host and file lookups to check lock state, operations that will be common across multiple NLM procedures being migrated to xdrgen. Introducing the nlm3svc_lookup_host() and nlm3svc_lookup_file() helpers now keeps these common patterns in one place for subsequent conversions in this series. This patch converts the TEST procedure to use xdrgen functions nlm_svc_decode_nlm_testargs and nlm_svc_encode_nlm_testres generated from the NLM version 3 protocol specification. The procedure handler is rewritten to use xdrgen types through wrapper structures that bridge between generated code and the legacy lockd_lock representation still used by the core lockd logic. Setting pc_argzero to zero is safe because the generated decoder fills the argp->xdrgen subfields before the procedure runs, so the zeroing memset performed by the dispatch layer is not needed. The lock member of the wrapper is populated explicitly in nlm3svc_lookup_file() rather than relying on zero-initialization. The conflicting holder's offset and length are saturated to NLM_OFFSET_MAX when constructing the reply. A conflicting lock established by an NLMv4 client or by a local process can sit beyond the NLMv3 signed 32-bit range, and copying fl_start and fl_end straight into the unsigned 32-bit XDR fields would wrap and report a bogus range. The previous hand-written encoder in svcxdr_encode_holder() used loff_t_to_s32() for the same reason, but this patch series intends to separate the concerns of data conversion (XDR) from dealing with local byte range constraints, so clamping is hoisted into the proc function. The previous hand-written decoder in svcxdr_decode_cookie() rewrote a zero-length NLM cookie into a four-byte zero cookie, with a comment attributing the substitution to HP-UX clients. The xdrgen-generated netobj decoder performs no such rewrite, so a zero-length request cookie now round-trips unchanged into the reply. HP-UX has reached end of support, and NLM_TEST reply matching relies on the RPC XID rather than the NLM cookie, so the workaround is dropped intentionally here. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Rename struct nlm_share to lockd_share

2026-06-09T20:32:59+00:00

As part of the effort to enable lockd's server-side XDR functions to be generated from the NLM protocol specification (using xdrgen), the internal type names must be changed to avoid conflicts with the machine-generated type names. Rename struct nlm_share to struct lockd_share to avoid conflicts with the NLMv3 XDR type definitions that will be introduced when svcproc.c is converted to use xdrgen. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Rename struct nlm_reboot to lockd_reboot

2026-06-09T20:32:59+00:00

As part of the effort to enable lockd's server-side XDR functions to be generated from the NLM protocol specification (using xdrgen), the internal type names must be changed to avoid conflicts with the machine-generated type names. Rename struct nlm_reboot to struct lockd_reboot for consistency with the other renamed internal types. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Rename struct nlm_res to lockd_res

2026-06-09T20:32:59+00:00

As part of the effort to enable lockd's server-side XDR functions to be generated from the NLM protocol specification (using xdrgen), the internal type names must be changed to avoid conflicts with the machine-generated type names. Rename struct nlm_res to struct lockd_res to avoid conflicts with the NLMv3 XDR type definitions that will be introduced when svcproc.c is converted to use xdrgen. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Rename struct nlm_args to lockd_args

2026-06-09T20:32:59+00:00

As part of the effort to enable lockd's server-side XDR functions to be generated from the NLM protocol specification (using xdrgen), the internal type names must be changed to avoid conflicts with the machine-generated type names. Rename struct nlm_args to struct lockd_args to avoid conflicts with the NLMv3 XDR type definitions that will be introduced when svcproc.c is converted to use xdrgen. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Rename struct nlm_lock to lockd_lock

2026-06-09T20:32:59+00:00

A subsequent patch will convert fs/lockd/svcproc.c to use machine-generated XDR encoding and decoding functions in a manner similar to fs/lockd/svc4proc.c. Machine-generated types derived from the NLM specification will conflict with the internal types of the same name. Rename the internal struct nlm_lock type to lockd_lock to avoid such naming conflicts. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Rename struct nlm_cookie to lockd_cookie

2026-06-09T20:32:59+00:00

Machine-generated XDR types derived from the NLM specification use names that match the protocol. Internal lockd types with identical names cause compilation failures when machine-generated encoders replace hand-coded ones. Rename the internal struct nlm_cookie type to lockd_cookie to prevent such collisions. The "lockd_" prefix distinguishes implementation-specific types from specified NLM protocol types. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: fix TEST handling when not all permissions are available.

2026-05-21T21:08:47+00:00

The F_GETLK fcntl can work with either read access or write access or both. It can query F_RDLCK and F_WRLCK locks in either case. However lockd currently treats F_GETLK similar to F_SETLK in that read access is required to query an F_RDLCK lock and write access is required to query a F_WRLCK lock. This is wrong and can cause problems - e.g. when qemu accesses a read-only (e.g. iso) filesystem image over NFS (though why it queries if it can get a write lock - I don't know. But it does, and this works with local filesystems). So we need TEST requests to be handled differently. To do this: - change nlm_do_fopen() to accept O_RDWR as a mode and in that case succeed if either a O_RDONLY or O_WRONLY file can be opened. - change nlm_lookup_file() to accept a mode argument from caller, instead of deducing base on lock time, and pass that on to nlm_do_fopen() - change nlm4svc_retrieve_args() and nlmsvc_retrieve_args() to detect TEST requests and pass O_RDWR as a mode to nlm_lookup_file, passing the same mode as before for other requests. Also set lock->fl.c.flc_file to whichever file is available for TEST requests. - change nlmsvc_testlock() to also not calculate the mode, but to use whatever was stored in lock->fl.c.flc_file. This behaviour of lockd - requesting O_WRONLY access to TEST for exclusive locks - has been present at least since git history began. However it was hidden until recently because knfsd ignored the access requested by lockd and required only READ access for all locking requests (unless the underlying filesystem provided an f_op->open function which checked access permissions). The commit mentioned in Fixes: below changed nfsd_permission() to NOT override the access request for LOCK requests and this exposed the bug that we are now fixing. Note that there is another issue that this patch does not address. The flock(.., LOCK_EX) call is permitted on a read-only file descriptor. Linux NFS maps this to NLM locking as whole-file byte-range locks. nfsd will see this as though it were fcntl( F_SETLK (F_WRLCK)) and will now require write access, which it might not be able to get. It is not clear if this is a problem in practice, or what the best solution might be. So no attempt is made to address it. Reported-by: Tj Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128861 Fixes: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK") Reviewed-by: Jeff Layton Signed-off-by: NeilBrown Signed-off-by: Chuck Lever

lockd: Remove dead code from fs/lockd/xdr4.c

2026-03-30T01:25:09+00:00

Now that all NLMv4 server-side procedures use XDR encoder and decoder functions generated by xdrgen, the hand-written code in fs/lockd/xdr4.c is no longer needed. This file contained the original XDR processing logic that has been systematically replaced throughout this series. Remove the file and its Makefile reference to eliminate the dead code. The helper function nlm4svc_set_file_lock_range() is still needed by the generated code, so move it to xdr4.h as an inline function where it remains accessible. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever