diff options
| author | Chuck Lever <chuck.lever@oracle.com> | 2026-05-12 21:13:59 +0300 |
|---|---|---|
| committer | Chuck Lever <cel@kernel.org> | 2026-06-09 23:32:59 +0300 |
| commit | 6c534ad999b6696bca55ded82bb7645fe6c5979e (patch) | |
| tree | f6437894dfed08060e1a0e5dcf1c112d7c9fee99 /include/linux | |
| parent | 6a2f89e49b4fb69aa6e04ed1c7cb202f0c38406e (diff) | |
| download | linux-6c534ad999b6696bca55ded82bb7645fe6c5979e.tar.xz | |
lockd: Use xdrgen XDR functions for the NLMv3 GRANTED_MSG procedure
Continue the xdrgen migration by converting NLMv3 GRANTED_MSG,
the async counterpart to GRANTED that a remote NLM uses to tell
this lockd that a previously blocked client lock request has
become available. The procedure now uses
nlm_svc_decode_nlm_testargs and nlm_svc_encode_void, generated
from the NLM version 3 protocol specification. The procedure
handler reaches the xdrgen types through the
nlm_testargs_wrapper structure, which bridges between generated
code and the legacy lockd_lock representation.
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 __nlmsvc_proc_granted_msg() by nlm_lock_to_lockd_lock()
rather than relying on zero-initialization.
The NLM async callback mechanism uses client-side functions
which continue to take legacy results like struct lockd_res,
preventing GRANTED and GRANTED_MSG from sharing code for now.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions
