kernel/git/stable/linux.git/fs/lockd/xdr4.c, branch master

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

lockd: Hoist file_lock init out of nlm4svc_decode_shareargs()

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

The xdrgen-generated XDR decoders cannot initialize the file_lock structure because it is an internal kernel type, not part of the wire protocol. To prepare for converting SHARE and UNSHARE procedures to use xdrgen, the file_lock initialization must be moved from nlm4svc_decode_shareargs() into the procedure handlers themselves. This change removes one more dependency on the "struct nlm_lock::fl" field in fs/lockd/xdr4.c, allowing the XDR decoder to focus solely on unmarshalling wire data. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Move nlm4svc_set_file_lock_range()

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

Both client-side and server-side NLMv4 code convert lock byte ranges from the wire format (start, length) to the kernel's file_lock format (start, end). The current nlm4svc_set_file_lock_range() performs this conversion, but the "svc" prefix incorrectly suggests server-only use, and client code must include server-internal headers to access it. Rename to lockd_set_file_lock_range4() and relocate to the shared lockd.h header, making it accessible to both client and server code. This eliminates the need for client code to include xdr4.h, reducing coupling between the XDR implementation files. While relocating the function, add input validation: clamp the starting offset to OFFSET_MAX before use. Without this, a malformed lock request with off > OFFSET_MAX results in fl_start > fl_end, violating file_lock invariants and potentially causing incorrect lock conflict detection. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Relocate include/linux/lockd/lockd.h

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

Headers placed in include/linux/ form part of the kernel's internal API and signal to subsystem maintainers that other parts of the kernel may depend on them. By moving lockd.h into fs/lockd/, lockd becomes a more self-contained module whose internal interfaces are clearly distinguished from its public contract with the rest of the kernel. This relocation addresses a long-standing XXX comment in the header itself that acknowledged the file's misplacement. Future changes to lockd internals can now proceed with confidence that external consumers are not inadvertently coupled to implementation details. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Move xdr4.h from include/linux/lockd/ to fs/lockd/

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

The xdr4.h header declares NLMv4-specific XDR encoder/decoder functions and error codes that are used exclusively within the lockd subsystem. Moving it from include/linux/lockd/ to fs/lockd/ clarifies the intended scope of these declarations and prevents external code from depending on lockd-internal interfaces. This change reduces the public API surface of the lockd module and makes it easier to refactor NLMv4 internals without risk of breaking out-of-tree consumers. The header's contents are implementation details of the NLMv4 wire protocol handling, not a contract with other kernel subsystems. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

lockd: Remove unneeded initialization of file_lock::c.flc_flags

2024-11-19T01:23:04+00:00

Since commit 75c7940d2a86 ("lockd: set missing fl_flags field when retrieving args"), nlmsvc_retrieve_args() initializes the flc_flags field. svcxdr_decode_lock() no longer needs to do this. This clean up removes one dependency on the nlm_lock:fl field. No behavior change is expected. Analysis: svcxdr_decode_lock() is called by: nlm4svc_decode_testargs() nlm4svc_decode_lockargs() nlm4svc_decode_cancargs() nlm4svc_decode_unlockargs() nlm4svc_decode_testargs() is used by: - NLMPROC4_TEST and NLMPROC4_TEST_MSG, which call nlmsvc_retrieve_args() - NLMPROC4_GRANTED and NLMPROC4_GRANTED_MSG, which don't pass the lock's file_lock to the generic lock API nlm4svc_decode_lockargs() is used by: - NLMPROC4_LOCK and NLM4PROC4_LOCK_MSG, which call nlmsvc_retrieve_args() - NLMPROC4_UNLOCK and NLM4PROC4_UNLOCK_MSG, which call nlmsvc_retrieve_args() - NLMPROC4_NM_LOCK, which calls nlmsvc_retrieve_args() nlm4svc_decode_cancargs() is used by: - NLMPROC4_CANCEL and NLMPROC4_CANCEL_MSG, which call nlmsvc_retrieve_args() nlm4svc_decode_unlockargs() is used by: - NLMPROC4_UNLOCK and NLMPROC4_UNLOCK_MSG, which call nlmsvc_retrieve_args() All callers except GRANTED/GRANTED_MSG eventually call nlmsvc_retrieve_args() before using nlm_lock::fl.c.flc_flags. Thus this change is safe. Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever

lockd: Remove unnecessary memset()

2024-11-19T01:23:03+00:00

Since commit 103cc1fafee4 ("SUNRPC: Parametrize how much of argsize should be zeroed") (and possibly long before that, even) all of the memory underlying rqstp->rq_argp is zeroed already. There's no need for the memset() in nlm4svc_decode_shareargs(). Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever

lockd: adapt to breakup of struct file_lock

2024-02-05T12:11:43+00:00

Most of the existing APIs have remained the same, but subsystems that access file_lock fields directly need to reach into struct file_lock_core now. Signed-off-by: Jeff Layton Link: https://lore.kernel.org/r/20240131-flsplit-v3-40-c6129007ee8d@kernel.org Reviewed-by: NeilBrown Signed-off-by: Christian Brauner

lockd: set file_lock start and end when decoding nlm4 testargs

2023-03-14T18:00:55+00:00

Commit 6930bcbfb6ce dropped the setting of the file_lock range when decoding a nlm_lock off the wire. This causes the client side grant callback to miss matching blocks and reject the lock, only to rerequest it 30s later. Add a helper function to set the file_lock range from the start and end values that the protocol uses, and have the nlm_lock decoder call that to set up the file_lock args properly. Fixes: 6930bcbfb6ce ("lockd: detect and reject lock arguments that overflow") Reported-by: Amir Goldstein Signed-off-by: Jeff Layton Tested-by: Amir Goldstein Cc: stable@vger.kernel.org #6.0 Signed-off-by: Anna Schumaker

lockd: detect and reject lock arguments that overflow

2022-08-04T14:28:48+00:00

lockd doesn't currently vet the start and length in nlm4 requests like it should, and can end up generating lock requests with arguments that overflow when passed to the filesystem. The NLM4 protocol uses unsigned 64-bit arguments for both start and length, whereas struct file_lock tracks the start and end as loff_t values. By the time we get around to calling nlm4svc_retrieve_args, we've lost the information that would allow us to determine if there was an overflow. Start tracking the actual start and len for NLM4 requests in the nlm_lock. In nlm4svc_retrieve_args, vet these values to ensure they won't cause an overflow, and return NLM4_FBIG if they do. Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=392 Reported-by: Jan Kasiak Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Cc: # 5.14+