[PATCH net-next 0/3] netlink: specs: fou: spec tweaks

[PATCH net-next 0/3] netlink: specs: fou: spec tweaks

[Jakub Kicinski]

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

[PATCH net-next 1/3] netlink: specs: fou: add af to the shared attribute list

[Jakub Kicinski]

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(+)

diff --git a/Documentation/netlink/specs/fou.yaml b/Documentation/netlink/specs/fou.yaml
index 331f1b342b3a..32d34be1dc63 100644
--- a/Documentation/netlink/specs/fou.yaml
+++ b/Documentation/netlink/specs/fou.yaml
@@ -90,6 +90,7 @@ kernel-policy: global
         request: &all_attrs
           attributes:
             - port
+            - af
             - ipproto
             - type
             - remcsum-nopartial
-- 
2.55.0

Re: [PATCH net-next 1/3] netlink: specs: fou: add af to the shared attribute list

[Nicolas Dichtel]

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>

Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>

Re: [PATCH net-next 1/3] netlink: specs: fou: add af to the shared attribute list

[netdev-bot+sashiko]

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.

> diff --git a/Documentation/netlink/specs/fou.yaml b/Documentation/netlink/specs/fou.yaml
> index 331f1b342b3ad..32d34be1dc63a 100644
> --- a/Documentation/netlink/specs/fou.yaml
> +++ b/Documentation/netlink/specs/fou.yaml
> @@ -90,6 +90,7 @@ operations:
>          request: &all_attrs
>            attributes:
>              - port
> +            - af

[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?

>              - ipproto
>              - type
>              - remcsum-nopartial

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260904191412.3872344-1-kuba%40kernel.org

[PATCH net-next 2/3] netlink: specs: fou: local-v4 and peer-v4 are big endian

[Jakub Kicinski]

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(-)

diff --git a/Documentation/netlink/specs/fou.yaml b/Documentation/netlink/specs/fou.yaml
index 32d34be1dc63..1d0db6ba7e52 100644
--- a/Documentation/netlink/specs/fou.yaml
+++ b/Documentation/netlink/specs/fou.yaml
@@ -50,6 +50,7 @@ kernel-policy: global
       -
         name: local-v4
         type: u32
+        byte-order: big-endian
       -
         name: local-v6
         type: binary
@@ -58,6 +59,7 @@ kernel-policy: global
       -
         name: peer-v4
         type: u32
+        byte-order: big-endian
       -
         name: peer-v6
         type: binary
diff --git a/net/ipv4/fou_nl.c b/net/ipv4/fou_nl.c
index 309d5ba983d0..cdb174b92cdd 100644
--- a/net/ipv4/fou_nl.c
+++ b/net/ipv4/fou_nl.c
@@ -18,9 +18,9 @@ const struct nla_policy fou_nl_policy[FOU_ATTR_IFINDEX + 1] = {
 	[FOU_ATTR_IPPROTO] = NLA_POLICY_MIN(NLA_U8, 1),
 	[FOU_ATTR_TYPE] = { .type = NLA_U8, },
 	[FOU_ATTR_REMCSUM_NOPARTIAL] = { .type = NLA_FLAG, },
-	[FOU_ATTR_LOCAL_V4] = { .type = NLA_U32, },
+	[FOU_ATTR_LOCAL_V4] = { .type = NLA_BE32, },
 	[FOU_ATTR_LOCAL_V6] = NLA_POLICY_EXACT_LEN(16),
-	[FOU_ATTR_PEER_V4] = { .type = NLA_U32, },
+	[FOU_ATTR_PEER_V4] = { .type = NLA_BE32, },
 	[FOU_ATTR_PEER_V6] = NLA_POLICY_EXACT_LEN(16),
 	[FOU_ATTR_PEER_PORT] = { .type = NLA_BE16, },
 	[FOU_ATTR_IFINDEX] = { .type = NLA_S32, },
-- 
2.55.0

Re: [PATCH net-next 2/3] netlink: specs: fou: local-v4 and peer-v4 are big endian

[Nicolas Dichtel]

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>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>

Re: [PATCH net-next 2/3] netlink: specs: fou: local-v4 and peer-v4 are big endian

[netdev-bot+sashiko]

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.

> diff --git a/Documentation/netlink/specs/fou.yaml b/Documentation/netlink/specs/fou.yaml
> index 32d34be1dc63a..1d0db6ba7e52b 100644
> --- a/Documentation/netlink/specs/fou.yaml
> +++ b/Documentation/netlink/specs/fou.yaml
> @@ -50,6 +50,7 @@ attribute-sets:
>        -
>          name: local-v4
>          type: u32
> +        byte-order: big-endian
>        -
>          name: local-v6
>          type: binary
> @@ -58,6 +59,7 @@ attribute-sets:
>        -
>          name: peer-v4
>          type: u32
> +        byte-order: big-endian
>        -
>          name: peer-v6
>          type: binary

[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?

> diff --git a/net/ipv4/fou_nl.c b/net/ipv4/fou_nl.c
> index 309d5ba983d04..cdb174b92cdd2 100644
> --- a/net/ipv4/fou_nl.c
> +++ b/net/ipv4/fou_nl.c
> @@ -18,9 +18,9 @@ const struct nla_policy fou_nl_policy[FOU_ATTR_IFINDEX + 1] = {
>  	[FOU_ATTR_IPPROTO] = NLA_POLICY_MIN(NLA_U8, 1),
>  	[FOU_ATTR_TYPE] = { .type = NLA_U8, },
>  	[FOU_ATTR_REMCSUM_NOPARTIAL] = { .type = NLA_FLAG, },
> -	[FOU_ATTR_LOCAL_V4] = { .type = NLA_U32, },
> +	[FOU_ATTR_LOCAL_V4] = { .type = NLA_BE32, },
>  	[FOU_ATTR_LOCAL_V6] = NLA_POLICY_EXACT_LEN(16),
> -	[FOU_ATTR_PEER_V4] = { .type = NLA_U32, },
> +	[FOU_ATTR_PEER_V4] = { .type = NLA_BE32, },

[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"?

>  	[FOU_ATTR_PEER_V6] = NLA_POLICY_EXACT_LEN(16),
>  	[FOU_ATTR_PEER_PORT] = { .type = NLA_BE16, },
>  	[FOU_ATTR_IFINDEX] = { .type = NLA_S32, },

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260904191412.3872344-1-kuba%40kernel.org

Re: [PATCH net-next 2/3] netlink: specs: fou: local-v4 and peer-v4 are big endian

[Paolo Abeni]

On 9/7/26 9:14 PM, netdev-bot+sashiko@kernel.org wrote:
> 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)…

FTR, I think the above may deserve a follow-up but it's not a blocker.

/P

[PATCH net-next 3/3] netlink: specs: fou: link the type attribute to the encap-type enum

[Jakub Kicinski]

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(-)

diff --git a/Documentation/netlink/specs/fou.yaml b/Documentation/netlink/specs/fou.yaml
index 1d0db6ba7e52..3e6a38e31202 100644
--- a/Documentation/netlink/specs/fou.yaml
+++ b/Documentation/netlink/specs/fou.yaml
@@ -44,6 +44,7 @@ kernel-policy: global
       -
         name: type
         type: u8
+        enum: encap-type
       -
         name: remcsum-nopartial
         type: flag
diff --git a/net/ipv4/fou_nl.c b/net/ipv4/fou_nl.c
index cdb174b92cdd..ccd134ba352d 100644
--- a/net/ipv4/fou_nl.c
+++ b/net/ipv4/fou_nl.c
@@ -16,7 +16,7 @@ const struct nla_policy fou_nl_policy[FOU_ATTR_IFINDEX + 1] = {
 	[FOU_ATTR_PORT] = { .type = NLA_BE16, },
 	[FOU_ATTR_AF] = { .type = NLA_U8, },
 	[FOU_ATTR_IPPROTO] = NLA_POLICY_MIN(NLA_U8, 1),
-	[FOU_ATTR_TYPE] = { .type = NLA_U8, },
+	[FOU_ATTR_TYPE] = NLA_POLICY_MAX(NLA_U8, 2),
 	[FOU_ATTR_REMCSUM_NOPARTIAL] = { .type = NLA_FLAG, },
 	[FOU_ATTR_LOCAL_V4] = { .type = NLA_BE32, },
 	[FOU_ATTR_LOCAL_V6] = NLA_POLICY_EXACT_LEN(16),
-- 
2.55.0

Re: [PATCH net-next 3/3] netlink: specs: fou: link the type attribute to the encap-type enum

[Nicolas Dichtel]

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 <nicolas.dichtel@6wind.com>

Side note: the field 'type' in 'struct fou_cfg' and 'struct fou' is a u16.
Having an u8 would be more consistent (:

Re: [PATCH net-next 0/3] netlink: specs: fou: spec tweaks

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Fri,  4 Sep 2026 12:14:09 -0700 you wrote:
> 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
> 
> [...]

Here is the summary with links:
  - [net-next,1/3] netlink: specs: fou: add af to the shared attribute list
    https://git.kernel.org/netdev/net-next/c/fc7aa4b30acf
  - [net-next,2/3] netlink: specs: fou: local-v4 and peer-v4 are big endian
    https://git.kernel.org/netdev/net-next/c/3f4285d741b4
  - [net-next,3/3] netlink: specs: fou: link the type attribute to the encap-type enum
    https://git.kernel.org/netdev/net-next/c/1859a0cc3adb

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html