kernel/git/stable/linux.git/tools/net/sunrpc, branch master

xdrgen: Reject out-of-range program, version, and procedure numbers

2026-08-10T13:54:35+00:00

RFC 5531 assigns only unsigned constants to program, version, and procedure numbers (Section 12.3) and encodes each as an unsigned 32-bit integer (Section 9), so a valid number falls within [0, 2**32 - 1]. RFC 4506 Section 6.2 permits a signed decimal constant for XDR constants in general and sets no ceiling on magnitude, so the grammar accepts an out-of-range value without complaint. It reaches generated code -- a negative procedure number emerges as an enumerator such as "FOO = -5", valid C that compiles cleanly even though the wire field is an unsigned 32-bit integer. Thus the xdrgen front end is the only place that can reject the malformed value. Extend the semantic checks to require each program, version, and procedure number to fall within [0, 2**32 - 1]. Link: https://patch.msgid.link/20260712203451.124902-6-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Enforce RFC 5531 name and number scoping for RPC programs

2026-08-10T13:54:35+00:00

The duplicate-identifier check enforces the RFC 4506 name space for XDR type and constant identifiers but ignores what an RPC program definition adds. RFC 5531 Section 12.3 completes the model: a program identifier shares the specification-wide name space with constant and type identifiers, a version name and number are unique within their program, and a procedure name and number are unique within their version. xdrgen currently accepts a specification that breaks any of these rules, and the symptom depends on which rule. A duplicate procedure name reaches the generated header as a redeclared enumerator, which the C compiler rejects. A duplicate procedure number is more dangerous because it is silent: the two procedures emit enumerators of equal value -- valid C that compiles cleanly -- leaving a dispatch collision to surface only at run time. A duplicate program name shares the specification-wide name space with constants and types and is caught alongside them. Extend the check to enforce RFC 5531 scoping in full. Link: https://patch.msgid.link/20260712203451.124902-5-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Reject specifications that define a name twice

2026-08-10T13:54:35+00:00

When an RPC specification defines the same type or constant name more than once, currently xdrgen emits every definition without complaint. The duplication surfaces later as a C compiler error about a redefined struct or function that points at generated code instead of the actual offending line in the .x source. RFC 4506 Section 6.4 places constant and type identifiers in a single name space that must be unique within a specification. Add a semantic check that enforces this rule. Link: https://patch.msgid.link/20260712203451.124902-4-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Record the source position of each declared identifier

2026-08-10T13:54:35+00:00

In preparation for semantic checks that reject a malformed specification, record where each declared identifier appears in the source so a diagnostic can point at the name in error. The transformer keeps each identifier's spelling but discards its position, retaining only the position of the enclosing definition. A caret built from that position falls on the definition keyword rather than on the identifier, because the definition production begins at the keyword. Store the identifier's own line and column on every named construct: constants, enumerated types and their enumerators, structs, unions, pointers, typedef declarations, and RPC program, version, and procedure names. The fields live on the AST base node and are keyword-only, so lark's positional construction of each node is unaffected; a construct whose position is not recorded leaves them zero. Link: https://patch.msgid.link/20260712203451.124902-3-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Align the error caret under tab-indented source

2026-08-10T13:54:35+00:00

When xdrgen reports a parse or transform error, it prints the offending source line followed by a caret marking the column. The source line is emitted with its tab characters intact, but the caret offset is computed from a tab-expanded copy of the text ahead of the column. A terminal expands the line's leading tabs relative to the four-space output indent, while the caret math expands the same tabs from column zero, so the two disagree whenever the line is indented with tabs and the caret lands past the token it should mark. Render the displayed line with its tabs already expanded so the line and the caret share one tab origin and the four-space indent cancels. Fold the now-identical line-and-caret formatting out of both error handlers into a single helper, so every caller reports the same aligned output. Link: https://patch.msgid.link/20260712203451.124902-2-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Fix opaque and string encoders for unbounded members

2026-08-10T13:54:35+00:00

The variable-length opaque and string encoder templates emit an unconditional bound check, "if (value->NAME.len > MAXSIZE) return false". XDR represents an unbounded specifier (opaque foo<>, string foo<>) as a maxsize of 0, so for an unbounded member the check degenerates to "len > 0" and the generated encoder refuses every non-empty value. The decoder does not share this defect. It delegates to xdrgen_decode_opaque() and xdrgen_decode_string(), which treat a maxlen of 0 as unbounded and skip the length check. The sibling variable-length array templates already guard their bound check with maxsize != "0". Guard the bound check the same way in each affected template -- the struct and pointer forms of both the opaque and string encoders -- so an unbounded member encodes a payload of any length while a bounded member keeps its limit. An explicit zero-length bound (foo<0>) parses to the same maxsize of 0 and so also skips the check; xdrgen does not distinguish it from the unbounded form, matching the decoder and the array encoders. Fixes: 4b132aacb076 ("tools: Add xdrgen") Link: https://patch.msgid.link/20260712193122.116845-6-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Do not declare union XDR functions in the definitions header

2026-08-10T13:54:35+00:00

Unlike the struct, enum, typedef, and pointer templates, the union definitions template also emits xdrgen_decode_*() and xdrgen_encode_*() prototypes for a public union into that header. Those prototypes name struct xdr_stream, which the definitions header neither includes nor forward-declares, so any translation unit that includes the definitions header without xdr.h already in scope draws -Wvisibility warnings. The same public prototypes are emitted into the declarations header, which does include , making the definitions-header copies redundant. Drop the prototype emission from the union definitions template so it matches the other type templates. Public unions keep their encode and decode prototypes through the declarations header. Fixes: 4b132aacb076 ("tools: Add xdrgen") Link: https://patch.msgid.link/20260712193122.116845-4-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Share void RPC procedure handlers across programs

2026-08-10T13:54:35+00:00

The generated server-side decoder and encoder for a void procedure argument or result are named after the RPC program (for example, nfs_svc_decode_void). xdrgen derives that prefix from the program name alone, not the version, so two versions of one program built into the same module emit the identical symbol. NFSv2 and NFSv3 both declare program NFS_PROGRAM; once both are converted, fs/nfsd fails to link with multiple definitions of nfs_svc_decode_void and nfs_svc_encode_void. A void handler carries no program- or version-specific behavior: each merely forwards to xdrgen_decode_void() or xdrgen_encode_void(). Define one shared pair, xdrgen_svc_decode_void() and xdrgen_svc_encode_void(), in the xdrgen builtins, and stop the program generator from emitting a per-program void handler. lockd is the one in-tree consumer that already emits per-program void handlers, so regenerate the NLMv3 and NLMv4 XDR code to drop nlm_svc_{decode,encode}_void() and nlm4_svc_{decode,encode}_void() and point both procedure tables at the shared handlers. The shared handlers are identical to the generated ones they replace, so no wire behavior changes. Only the server (svc) handlers are affected. The client-side void stubs remain static and per-program, so they do not collide. Link: https://patch.msgid.link/20260712193122.116845-3-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Emit a blank line ahead of enum declarations

2026-08-10T13:54:35+00:00

Clean up. The declaration templates for structs, pointers, and typedefs each begin with a blank line, which keeps successive declarations and the include block above them visually separated. The enum declaration template omits that blank line. trim_blocks collapses the template's lone comment line to nothing, so the omission stayed invisible as long as every generated header happened to lead with a non-enum declaration. Fixes: 4329010ad9c3 ("xdrgen: Address some checkpatch whitespace complaints") Link: https://patch.msgid.link/20260712193122.116845-2-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Implement pass-through lines in specifications

2026-01-29T14:48:33+00:00

XDR specification files can contain lines prefixed with '%' that pass through unchanged to generated output. Traditional rpcgen removes the '%' and emits the remainder verbatim, allowing direct insertion of C includes, pragma directives, or other language- specific content into the generated code. Until now, xdrgen silently discarded these lines during parsing. This prevented specifications from including necessary headers or preprocessor directives that might be required for the generated code to compile correctly. The grammar now captures pass-through lines instead of ignoring them. A new AST node type represents pass-through content, and the AST transformer strips the leading '%' character. Definition and source generators emit pass-through content in document order, preserving the original placement within the specification. This brings xdrgen closer to feature parity with traditional rpcgen while maintaining the existing document-order processing model. Existing generated xdrgen source code has been regenerated. Signed-off-by: Chuck Lever