diff options
| author | Chuck Lever <chuck.lever@oracle.com> | 2026-05-12 21:13:56 +0300 |
|---|---|---|
| committer | Chuck Lever <cel@kernel.org> | 2026-06-09 23:32:59 +0300 |
| commit | 438c9af3b135b614b9ea771456f1d441b3291cb5 (patch) | |
| tree | 84653767b501520cad131b11e52f80ae8bfb24c7 /include/linux | |
| parent | ba4c62bb35ad5705a2a01d66cb5b6142bff1854e (diff) | |
| download | linux-438c9af3b135b614b9ea771456f1d441b3291cb5.tar.xz | |
lockd: Use xdrgen XDR functions for the NLMv3 LOCK_MSG procedure
Continue the xdrgen migration by converting NLMv3 LOCK_MSG, the
async counterpart to LOCK that clients use to request locks that
may block. The procedure now uses nlm_svc_decode_nlm_lockargs and
nlm_svc_encode_void, generated from the NLM version 3 protocol
specification. The procedure handler reaches the xdrgen types
through the nlm_lockargs_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
nlm3svc_lookup_file() 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
LOCK and LOCK_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
