kernel/git/stable/linux.git/tools/net, branch linux-6.12.y

xdrgen: Fix opaque and string encoders for unbounded members

2026-09-14T11:32:39+00:00

[ Upstream commit daa52e37851a5a1b5890e7a250a27e94a8b9f273 ] 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 Signed-off-by: Sasha Levin

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

2026-09-14T11:32:39+00:00

[ Upstream commit d4ca0b0a6c62bc12407060754df11b23a90f3e57 ] 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 Signed-off-by: Sasha Levin

xdrgen: Address some checkpatch whitespace complaints

2026-09-14T11:32:39+00:00

[ Upstream commit 4329010ad9c36775e7092e451c37c24c4f90243f ] This is a roll-up of three template fixes that eliminate noise from checkpatch output so that it's easier to spot non-trivial problems. To follow conventional kernel C style, when a union declaration is marked with "pragma public", there should be a blank line between the emitted "union xxx { ... };" and the decoder and encoder function declarations. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Stable-dep-of: d4ca0b0a6c62 ("xdrgen: Do not declare union XDR functions in the definitions header") Signed-off-by: Sasha Levin

xdrgen: Implement big-endian enums

2026-09-14T11:32:39+00:00

[ Upstream commit b376d519bd142c65ba9bba35db12b6be95b46893 ] Signed-off-by: Chuck Lever Stable-dep-of: d4ca0b0a6c62 ("xdrgen: Do not declare union XDR functions in the definitions header") Signed-off-by: Sasha Levin

xdrgen: Rename "enum yada" types as just "yada"

2026-09-14T11:32:39+00:00

[ Upstream commit 6e853dcd2d3d6f796597c1042340a2de0ce2469f ] This simplifies the generated C code and makes way for supporting big-endian XDR enums. Signed-off-by: Chuck Lever Stable-dep-of: d4ca0b0a6c62 ("xdrgen: Do not declare union XDR functions in the definitions header") Signed-off-by: Sasha Levin

xdrgen: Fix struct prefix for typedef types in program wrappers

2026-03-04T12:20:04+00:00

[ Upstream commit bf0fe9ad3d597d8e1378dc9953ca96dfc3addb2b ] The program templates for decoder/argument.j2 and encoder/result.j2 unconditionally add 'struct' prefix to all types. This is incorrect when an RPC protocol specification lists a typedef'd basic type or an enum as a procedure argument or result (e.g., NFSv2's fhandle or stat), resulting in compiler errors when building generated C code. Fixes: 4b132aacb076 ("tools: Add xdrgen") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin

tools: ynl: Specify --no-line-number in ynl-regen.sh.

2026-01-30T09:28:39+00:00

[ Upstream commit 68578370f9b3a2aba5964b273312d51c581b6aad ] If grep.lineNumber is enabled in .gitconfig, [grep] lineNumber = true ynl-regen.sh fails with the following error: $ ./tools/net/ynl/ynl-regen.sh -f ... ynl_gen_c.py: error: argument --mode: invalid choice: '4:' (choose from user, kernel, uapi) GEN 4: net/ipv4/fou_nl.c Let's specify --no-line-number explicitly. Fixes: be5bea1cc0bf ("net: add basic C code generators for Netlink") Suggested-by: Jakub Kicinski Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260115172533.693652-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

tools: ynl: fix string attribute length to include null terminator

2025-11-13T20:33:58+00:00

[ Upstream commit 65f9c4c5888913c2cf5d2fc9454c83f9930d537d ] The ynl_attr_put_str() function was not including the null terminator in the attribute length calculation. This caused kernel to reject CTRL_CMD_GETFAMILY requests with EINVAL: "Attribute failed policy validation". For a 4-character family name like "dpll": - Sent: nla_len=8 (4 byte header + 4 byte string without null) - Expected: nla_len=9 (4 byte header + 5 byte string with null) The bug was introduced in commit 15d2540e0d62 ("tools: ynl: check for overflow of constructed messages") when refactoring from stpcpy() to strlen(). The original code correctly included the null terminator: end = stpcpy(ynl_attr_data(attr), str); attr->nla_len = NLA_HDRLEN + NLA_ALIGN(end - (char *)ynl_attr_data(attr)); Since stpcpy() returns a pointer past the null terminator, the length included it. The refactored version using strlen() omitted the +1. The fix also removes NLA_ALIGN() from nla_len calculation, since nla_len should contain actual attribute length, not aligned length. Alignment is only for calculating next attribute position. This makes the code consistent with ynl_attr_put(). CTRL_ATTR_FAMILY_NAME uses NLA_NUL_STRING policy which requires null terminator. Kernel validates with memchr() and rejects if not found. Fixes: 15d2540e0d62 ("tools: ynl: check for overflow of constructed messages") Signed-off-by: Petr Oros Tested-by: Ivan Vecera Reviewed-by: Ivan Vecera Link: https://lore.kernel.org/20251018151737.365485-3-zahari.doychev@linux.com Link: https://patch.msgid.link/20251024132438.351290-1-poros@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

tools: ynl-gen: validate 0 len strings from kernel

2025-05-29T09:03:12+00:00

[ Upstream commit 4720f9707c783f642332dee3d56dccaefa850e42 ] Strings from the kernel are guaranteed to be null terminated and ynl_attr_validate() checks for this. But it doesn't check if the string has a len of 0, which would cause problems when trying to access data[len - 1]. Fix this by checking that len is positive. Signed-off-by: David Wei Link: https://patch.msgid.link/20250503043050.861238-1-dw@davidwei.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

tools: ynl-gen: don't output external constants

2025-05-29T09:03:00+00:00

[ Upstream commit 7e8b24e24ac46038e48c9a042e7d9b31855cbca5 ] A definition with a "header" property is an "external" definition for C code, as in it is defined already in another C header file. Other languages will need the exact value but C codegen should not recreate it. So don't output those definitions in the uAPI header. Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20250203215510.1288728-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin