[PATCH net-next] netlink: specs: add big-endian byte-order for u32 IPv4 addresses

[PATCH net-next] netlink: specs: add big-endian byte-order for u32 IPv4 addresses

[Hangbin Liu]

The fix commit converted several IPv4 address attributes from binary
to u32, but forgot to specify byte-order: big-endian. Without this,
YNL tools display IPv4 addresses incorrectly due to host-endian
interpretation.

Add the missing byte-order: big-endian to all affected u32 IPv4
address fields to ensure correct parsing and display.

Fixes: 1064d521d177 ("netlink: specs: support ipv4-or-v6 for dual-stack fields")
Reported-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
 Documentation/netlink/specs/rt-addr.yaml | 1 +
 Documentation/netlink/specs/rt-link.yaml | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Documentation/netlink/specs/rt-addr.yaml b/Documentation/netlink/specs/rt-addr.yaml
index abcbaa73fa9d..163a106c41bb 100644
--- a/Documentation/netlink/specs/rt-addr.yaml
+++ b/Documentation/netlink/specs/rt-addr.yaml
@@ -97,6 +97,7 @@ attribute-sets:
       -
         name: broadcast
         type: u32
+        byte-order: big-endian
         display-hint: ipv4
       -
         name: anycast
diff --git a/Documentation/netlink/specs/rt-link.yaml b/Documentation/netlink/specs/rt-link.yaml
index ca22c68ca691..6beeb6ee5adf 100644
--- a/Documentation/netlink/specs/rt-link.yaml
+++ b/Documentation/netlink/specs/rt-link.yaml
@@ -1869,6 +1869,7 @@ attribute-sets:
       -
         name: remote
         type: u32
+        byte-order: big-endian
         display-hint: ipv4
       -
         name: ttl
@@ -1987,6 +1988,7 @@ attribute-sets:
       -
         name: 6rd-relay-prefix
         type: u32
+        byte-order: big-endian
         display-hint: ipv4
       -
         name: 6rd-prefixlen
-- 
2.50.1

Re: [PATCH net-next] netlink: specs: add big-endian byte-order for u32 IPv4 addresses

[Asbjørn Sloth Tønnesen]

On 11/25/25 11:20 AM, Hangbin Liu wrote:
> The fix commit converted several IPv4 address attributes from binary
> to u32, but forgot to specify byte-order: big-endian. Without this,
> YNL tools display IPv4 addresses incorrectly due to host-endian
> interpretation.
> 
> Add the missing byte-order: big-endian to all affected u32 IPv4
> address fields to ensure correct parsing and display.
> 
> Fixes: 1064d521d177 ("netlink: specs: support ipv4-or-v6 for dual-stack fields")
> Reported-by: Paolo Abeni <pabeni@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>

LGTM

Reviewed-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>

I also checked how consistently defined the fields using the ipv6 display helper are,
and it looks like they could use some realignment too. Obviously not for this fix.

git grep -C6 'display-hint.*ipv6$' Documentation/netlink/specs/

Re: [PATCH net-next] netlink: specs: add big-endian byte-order for u32 IPv4 addresses

[Hangbin Liu]

Hi,
On Tue, Nov 25, 2025 at 05:03:13PM +0000, Asbjørn Sloth Tønnesen wrote:
> I also checked how consistently defined the fields using the ipv6 display helper are,
> and it looks like they could use some realignment too. Obviously not for this fix.
> 
> git grep -C6 'display-hint.*ipv6$' Documentation/netlink/specs/

The ip6gre spec shows
-
  name: local
  display-hint: ipv6
-
  name: remote
  display-hint: ipv6

The dump result looks good. So for others ipv6 field, what alignment should we
use? Should we add checks: min-len: 16? Do we need byte-order: big-endian?

Thanks
Hangbin

Re: [PATCH net-next] netlink: specs: add big-endian byte-order for u32 IPv4 addresses

[Asbjørn Sloth Tønnesen]

On 11/26/25 6:36 AM, Hangbin Liu wrote:
> Hi,
> On Tue, Nov 25, 2025 at 05:03:13PM +0000, Asbjørn Sloth Tønnesen wrote:
>> I also checked how consistently defined the fields using the ipv6 display helper are,
>> and it looks like they could use some realignment too. Obviously not for this fix.
>>
>> git grep -C6 'display-hint.*ipv6$' Documentation/netlink/specs/
> 
> The ip6gre spec shows
> -
>    name: local
>    display-hint: ipv6
> -
>    name: remote
>    display-hint: ipv6
> 
> The dump result looks good.

Those two are defined in linkinfo-gre6-attrs, which is declared as a subset-of
linkinfo-gre-attrs.

In linkinfo-gre-attrs they are declared as:

-
   name: local
   type: binary
   display-hint: ipv4-or-v6
-
   name: remote
   type: binary
   display-hint: ipv4-or-v6

I have tested with deleting one or the other's display-helper, and at least
in cli.py, this kind of display-hint overloading works.

> So for others ipv6 field, what alignment should we
> use? Should we add checks: min-len: 16? Do we need byte-order: big-endian?

IPv6 is always big-endian, the marking first becomes needed when/if we make
them an u128 type. Until then it would just be nice if either all or none
of them had the big-endian marking.

I prefer exact-len over min-len. The current tally is:

$ git grep 'len.*: 16' Documentation/netlink/specs/ | cut -d: -f2- | sed -e 's/^ *//' | sort | uniq -c
       7 exact-len: 16
       5 len: 16
       6 min-len: 16
(assuming that only IPv6 has a length of 16)

"len: 16" as used in ovs_flow's ipv6-src and ipv6-dst only works because they
are struct members, not attributes.

Re: [PATCH net-next] netlink: specs: add big-endian byte-order for u32 IPv4 addresses

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue, 25 Nov 2025 11:20:48 +0000 you wrote:
> The fix commit converted several IPv4 address attributes from binary
> to u32, but forgot to specify byte-order: big-endian. Without this,
> YNL tools display IPv4 addresses incorrectly due to host-endian
> interpretation.
> 
> Add the missing byte-order: big-endian to all affected u32 IPv4
> address fields to ensure correct parsing and display.
> 
> [...]

Here is the summary with links:
  - [net-next] netlink: specs: add big-endian byte-order for u32 IPv4 addresses
    https://git.kernel.org/netdev/net-next/c/651765e8d527

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

Re: [PATCH net-next] netlink: specs: add big-endian byte-order for u32 IPv4 addresses

[Hangbin Liu]

On Wed, Nov 26, 2025 at 01:32:22PM +0000, Asbjørn Sloth Tønnesen wrote:
> On 11/26/25 6:36 AM, Hangbin Liu wrote:
> > Hi,
> > On Tue, Nov 25, 2025 at 05:03:13PM +0000, Asbjørn Sloth Tønnesen wrote:
> > > I also checked how consistently defined the fields using the ipv6 display helper are,
> > > and it looks like they could use some realignment too. Obviously not for this fix.
> > > 
> > > git grep -C6 'display-hint.*ipv6$' Documentation/netlink/specs/
> > 
> > The ip6gre spec shows
> > -
> >    name: local
> >    display-hint: ipv6
> > -
> >    name: remote
> >    display-hint: ipv6
> > 
> > The dump result looks good.
> 
> Those two are defined in linkinfo-gre6-attrs, which is declared as a subset-of
> linkinfo-gre-attrs.
> 
> In linkinfo-gre-attrs they are declared as:
> 
> -
>   name: local
>   type: binary
>   display-hint: ipv4-or-v6
> -
>   name: remote
>   type: binary
>   display-hint: ipv4-or-v6
> 
> I have tested with deleting one or the other's display-helper, and at least
> in cli.py, this kind of display-hint overloading works.
> 
> > So for others ipv6 field, what alignment should we
> > use? Should we add checks: min-len: 16? Do we need byte-order: big-endian?
> 
> IPv6 is always big-endian, the marking first becomes needed when/if we make
> them an u128 type. Until then it would just be nice if either all or none
> of them had the big-endian marking.
> 
> I prefer exact-len over min-len. The current tally is:
> 
> $ git grep 'len.*: 16' Documentation/netlink/specs/ | cut -d: -f2- | sed -e 's/^ *//' | sort | uniq -c
>       7 exact-len: 16
>       5 len: 16
>       6 min-len: 16
> (assuming that only IPv6 has a length of 16)
> 
> "len: 16" as used in ovs_flow's ipv6-src and ipv6-dst only works because they
> are struct members, not attributes.

Hmm, I just found that I tried to do that 2 years ago[1] but forgot why I give
up... I saw you have fixed the fou part with 9f9581ba74a9
("netlink: specs: fou: change local-v6/peer-v6 check").

Let's alignment others this time.

[1] https://lore.kernel.org/netdev/20231215035009.498049-4-liuhangbin@gmail.com/

Thanks
Hangbin

Re: [PATCH net-next] netlink: specs: add big-endian byte-order for u32 IPv4 addresses

[Hangbin Liu]

On Wed, Nov 26, 2025 at 01:32:22PM +0000, Asbjørn Sloth Tønnesen wrote:
> I prefer exact-len over min-len. The current tally is:
> 
> $ git grep 'len.*: 16' Documentation/netlink/specs/ | cut -d: -f2- | sed -e 's/^ *//' | sort | uniq -c
>       7 exact-len: 16
>       5 len: 16
>       6 min-len: 16
> (assuming that only IPv6 has a length of 16)
> 
> "len: 16" as used in ovs_flow's ipv6-src and ipv6-dst only works because they
> are struct members, not attributes.


Talking about the ovs, it's looks like that the struct members are used in
flow metadata, like in ip_tun_from_nlattr():

                case OVS_TUNNEL_KEY_ATTR_IPV6_SRC:
                        SW_FLOW_KEY_PUT(match, tun_key.u.ipv6.src,
                                        nla_get_in6_addr(a), is_mask);
                        ipv6 = true;
                        break;

While attributes are used in __ip_tun_to_nlattr():

        case AF_INET6:
                if (!ipv6_addr_any(&output->u.ipv6.src) &&
                    nla_put_in6_addr(skb, OVS_TUNNEL_KEY_ATTR_IPV6_SRC,
                                     &output->u.ipv6.src))
                        return -EMSGSIZE;

So I think we can also convert the ipv6-src/ipv6-dst using exact-len? WDYT?

Thanks
Hangbin