From: Jakub Kicinski <kuba@kernel.org> Date: 2026-09-04 19:14:21
FOU was one of the initial families I used to develop YNL against.
It's not using YNL features which were added later, fill in the gaps.
Jakub Kicinski (3):
netlink: specs: fou: add af to the shared attribute list
netlink: specs: fou: local-v4 and peer-v4 are big endian
netlink: specs: fou: link the type attribute to the encap-type enum
Documentation/netlink/specs/fou.yaml | 4 ++++
net/ipv4/fou_nl.c | 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
--
2.55.0
From: Jakub Kicinski <kuba@kernel.org> Date: 2026-09-04 19:14:39
parse_nl_config() is the only place the address family is chosen: it
defaults cfg->udp_config.family to AF_INET and only switches to
AF_INET6 when FOU_ATTR_AF is present. The &all_attrs anchor - the add
request, and the get do and dump reply - does not list af, so a ynl
generated client has no fou_add_req_set_af() and can never create an
IPv6 FOU port; the local-v6 / peer-v6 attributes it does list are read
by nothing. On the reply side fou_fill_info() puts FOU_ATTR_AF
unconditionally, and struct fou_get_rsp has no member for it.
kernel-policy is global, so fou_nl_ops[] carries no per-op attribute
list and af is already in fou_nl_policy through &select_attrs - only
the user space codegen and the rendered docs change, ynl-regen.sh
produces no diff.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Documentation/netlink/specs/fou.yaml | 1 +
1 file changed, 1 insertion(+)
From: Jakub Kicinski <kuba@kernel.org> Date: 2026-09-04 19:14:39
fou_core.c uses nla_get_in_addr() / nla_put_in_addr() on both, i.e.
they are __be32, and port / peer-port in the same spec are already
annotated. Without byte-order YNL swaps them on little endian hosts.
The generated policy goes from NLA_U32 to NLA_BE32, which changes
nothing: lib/nlattr.c gives the two the same length in nla_attr_len[]
and the same range handling, and neither attribute has a range check.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Documentation/netlink/specs/fou.yaml | 2 ++
net/ipv4/fou_nl.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
From: Jakub Kicinski <kuba@kernel.org> Date: 2026-09-04 19:14:41
The spec defines encap-type (unspec / direct / gue), but no attribute
references it, so the definition exists only to emit FOU_ENCAP_* into
the uAPI header - while FOU_ATTR_TYPE is exactly that value space:
fou_create() switches on FOU_ENCAP_DIRECT / FOU_ENCAP_GUE and returns
-EINVAL for anything else. Python YNL could not accept or display the
names and the generated C exposed a raw __u8 setter.
The global policy entry becomes NLA_POLICY_MAX(NLA_U8, 2). For add
that only moves the existing fou_create() rejection earlier; del and
get ignore FOU_ATTR_TYPE altogether, so a bogus type there now fails
validation instead of being dropped on the floor.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Documentation/netlink/specs/fou.yaml | 1 +
net/ipv4/fou_nl.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
From: Nicolas Dichtel <hidden> Date: 2026-09-07 10:04:34
Le 04/09/2026 à 21:14, Jakub Kicinski a écrit :
parse_nl_config() is the only place the address family is chosen: it
defaults cfg->udp_config.family to AF_INET and only switches to
AF_INET6 when FOU_ATTR_AF is present. The &all_attrs anchor - the add
request, and the get do and dump reply - does not list af, so a ynl
generated client has no fou_add_req_set_af() and can never create an
IPv6 FOU port; the local-v6 / peer-v6 attributes it does list are read
by nothing. On the reply side fou_fill_info() puts FOU_ATTR_AF
unconditionally, and struct fou_get_rsp has no member for it.
kernel-policy is global, so fou_nl_ops[] carries no per-op attribute
list and af is already in fou_nl_policy through &select_attrs - only
the user space codegen and the rendered docs change, ynl-regen.sh
produces no diff.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
From: Nicolas Dichtel <hidden> Date: 2026-09-07 10:05:07
Le 04/09/2026 à 21:14, Jakub Kicinski a écrit :
fou_core.c uses nla_get_in_addr() / nla_put_in_addr() on both, i.e.
they are __be32, and port / peer-port in the same spec are already
annotated. Without byte-order YNL swaps them on little endian hosts.
The generated policy goes from NLA_U32 to NLA_BE32, which changes
nothing: lib/nlattr.c gives the two the same length in nla_attr_len[]
and the same range handling, and neither attribute has a range check.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
From: Nicolas Dichtel <hidden> Date: 2026-09-07 10:05:29
Le 04/09/2026 à 21:14, Jakub Kicinski a écrit :
The spec defines encap-type (unspec / direct / gue), but no attribute
references it, so the definition exists only to emit FOU_ENCAP_* into
the uAPI header - while FOU_ATTR_TYPE is exactly that value space:
fou_create() switches on FOU_ENCAP_DIRECT / FOU_ENCAP_GUE and returns
-EINVAL for anything else. Python YNL could not accept or display the
names and the generated C exposed a raw __u8 setter.
The global policy entry becomes NLA_POLICY_MAX(NLA_U8, 2). For add
that only moves the existing fou_create() rejection earlier; del and
get ignore FOU_ATTR_TYPE altogether, so a bogus type there now fails
validation instead of being dropped on the floor.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Nicolas Dichtel <redacted>
Side note: the field 'type' in 'struct fou_cfg' and 'struct fou' is a u16.
Having an u8 would be more consistent (:
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 0 · Low: 1
- [Low] Missing `Fixes:` tag on a user-visible ynl/uAPI-codegen fix.
--
netlink: specs: fou: add af to the shared attribute list
The fou spec's &all_attrs anchor, used by the add do request and the get
do/dump reply, did not list the af attribute. This patch adds it, so ynl
generated clients gain a setter for it and the get reply struct gains a
member. Only user space codegen and the rendered docs change.
[Severity: Low]
Would a Fixes: tag be appropriate here?
git blame shows the &all_attrs anchor lines, including the local-v6 /
peer-v6 entries, come from 4eb77b4ecd3c ("netlink: add a proto
specification for FOU"); the only later touch, 791a9ed0a40d ("netlink:
specs: fou: replace underscores with dashes in names"), just renamed
names.
The effect described in the commit message is user visible: since
parse_nl_config() in net/ipv4/fou_core.c is the only place the family is
chosen and only switches away from AF_INET when FOU_ATTR_AF is present, a
generated client had no way to create an IPv6 FOU port, and fou_fill_info()
puts FOU_ATTR_AF unconditionally so the reply struct was missing a member
for an attribute present in every reply.
The same file has precedent for tagging a spec-only change:
791a9ed0a40d carried Fixes: 4eb77b4ecd3c ("netlink: add a proto
specification for FOU").
Without the tag, would a stable backporter have to bisect the spec history
to find where the omission came from?
Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 1 · Low: 1
- [Medium] Switching `FOU_ATTR_LOCAL_V4` / `FOU_ATTR_PEER_V4` from
`NLA_U32` to `NLA_BE32` in `fou_nl_policy[]` (net/ipv4/fou_nl.c:21,23)…
- [Low] The patch fixes a real, user-visible YNL byte-order defect
(missing `byte-order: big-endian` on fou's `local-v4`/`peer-v4`) but…
--
netlink: specs: fou: local-v4 and peer-v4 are big endian
This adds byte-order: big-endian to the local-v4 and peer-v4 attributes in
the fou netlink spec, since fou_core.c treats both as __be32 via
nla_get_in_addr() / nla_put_in_addr(). The regenerated policy in
net/ipv4/fou_nl.c changes the two entries from NLA_U32 to NLA_BE32.
No Link: tags present in the commit header.
[Severity: Low]
Should this carry a Fixes: tag? The commit message describes a
user-visible YNL defect ("Without byte-order YNL swaps them on little
endian hosts"), and the annotations were missing from the moment the spec
was added by commit 4eb77b4ecd3c ("netlink: add a proto specification for
FOU").
The kernel side has always treated both as network-order addresses:
net/ipv4/fou_core.c:parse_nl_config() {
...
cfg->udp_config.local_ip.s_addr = nla_get_in_addr(attr);
...
}
net/ipv4/fou_core.c:fou_fill_info() {
...
if (nla_put_in_addr(msg, FOU_ATTR_LOCAL_V4, sk->sk_rcv_saddr))
...
}
so a ynl client on a little-endian host configures and displays a reversed
address. Would adding:
Fixes: 4eb77b4ecd3c ("netlink: add a proto specification for FOU")
let backport tooling pick this up?
[Severity: Medium]
The commit message says the policy change "changes nothing". Is that
accurate for policy introspection as well as for validation?
The validation claim holds: nla_attr_len[] in lib/nlattr.c gives NLA_BE32
and NLA_U32 the same length, the range handling is shared, and neither
attribute has a range check.
But the policy dump has no NLA_BE16/NLA_BE32 arm, so NLA_BE32 lands in the
default case that is shared with NLA_UNSPEC and NLA_REJECT:
net/netlink/policy.c:__netlink_policy_dump_write_attr() {
...
switch (pt->type) {
default:
case NLA_UNSPEC:
case NLA_REJECT:
/* skip - use NLA_MIN_LEN to advertise such */
nla_nest_cancel(skb, attr);
return -ENODATA;
...
}
and the caller turns -ENODATA into "skip this attribute":
net/netlink/policy.c:netlink_policy_dump_write() {
...
err = __netlink_policy_dump_write_attr(state, skb, pt, state->attr_idx);
if (err == -ENODATA) {
nla_nest_cancel(skb, policy);
again = true;
goto next;
}
...
}
fou registers fou_nl_policy family-wide (.policy = fou_nl_policy in
fou_nl_family), so this is the policy exported through CTRL_CMD_GETPOLICY.
Does that mean FOU_ATTR_LOCAL_V4 and FOU_ATTR_PEER_V4 disappear from the
policy dump, where they previously showed up as NL_ATTR_TYPE_U32 with a
0..U32_MAX range?
Tooling that feature-probes attributes via the policy dump (ynl, the
wireshark netlink dissector) would then see them as absent. FOU_ATTR_PORT
and FOU_ATTR_PEER_PORT already have the same problem as NLA_BE16, so would
it make sense to add NLA_BE16/NLA_BE32 cases to
__netlink_policy_dump_write_attr(), or at least to mention this in the
changelog instead of "changes nothing"?