Re: [PATCH net-next 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support

On Fri, Sep 18, 2026 at 06:36:56AM +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] netlink: missing byte-order: big-endian in rt-route specs

Thanks, I will fix all these byte order issue.

> --
> 
> commit 18041b529d7678ae7bbdd8ee61a7fb4213ae6804
> Author: Hangbin Liu <[email protected]>
> 
> netlink: specs: rt-route: add lwtunnel encap sub-message support
> 
> This commit adds lwtunnel encapsulation sub-message support to the rt-route
> netlink specs, defining various tunnel attribute sets such as mpls, ip, ip6,
> seg6, bpf, etc. It updates the yaml spec for rt-route and adds necessary
> headers to the Makefile dependencies.
> 
> > diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> > index 253037ea5176a..0e236da140dc5 100644
> > --- a/Documentation/netlink/specs/rt-route.yaml
> > +++ b/Documentation/netlink/specs/rt-route.yaml
> [ ... ]
> > @@ -277,6 +332,229 @@ attribute-sets:
> >        -
> >          name: fastopen-no-cookie
> >          type: u32
> [ ... ]
> > +  -
> > +    name: lwtunnel-ip
> > +    name-prefix: lwtunnel-ip-
> > +    header: linux/lwtunnel.h
> > +    attributes:
> > +      -
> > +        name: id
> > +        type: u64
> 
> [Severity: High]
> Does this field need a byte-order: big-endian annotation? The kernel
> reads LWTUNNEL_IP_ID as be64 using nla_get_be64(). Without the annotation,
> YNL tools will byte-swap this on little-endian architectures, potentially
> causing silent data corruption.
> 
> > +      -
> > +        name: dst
> > +        type: u32
> > +        byte-order: big-endian
> > +        display-hint: ipv4
> > +      -
> > +        name: src
> > +        type: u32
> > +        byte-order: big-endian
> > +        display-hint: ipv4
> > +      -
> > +        name: ttl
> > +        type: u8
> > +      -
> > +        name: tos
> > +        type: u8
> > +      -
> > +        name: flags
> > +        type: u16
> 
> [Severity: High]
> Does this field also need a byte-order: big-endian annotation? The kernel
> reads LWTUNNEL_IP_FLAGS as be16 using nla_get_be16().
> 
> [ ... ]
> > +  -
> > +    name: lwtunnel-ip6
> > +    name-prefix: lwtunnel-ip6-
> > +    header: linux/lwtunnel.h
> > +    attributes:
> > +      -
> > +        name: id
> > +        type: u64
> 
> [Severity: High]
> Could this also be missing a byte-order: big-endian annotation? The kernel
> reads LWTUNNEL_IP6_ID as be64.
> 
> [ ... ]
> > +      -
> > +        name: hoplimit
> > +        type: u8
> > +      -
> > +        name: tc
> > +        type: u8
> > +      -
> > +        name: flags
> > +        type: u16
> 
> [Severity: High]
> Could this also be missing a byte-order: big-endian annotation? The kernel
> reads LWTUNNEL_IP6_FLAGS as be16.
> 
> [ ... ]
> > +  -
> > +    name: seg6-local
> > +    name-prefix: seg6-local-
> > +    header: linux/seg6_local.h
> > +    attributes:
> [ ... ]
> > +      -
> > +        name: table
> > +        type: u32
> > +      -
> > +        name: nh4
> > +        type: u32
> > +        display-hint: ipv4
> 
> [Severity: High]
> Does this field need a byte-order: big-endian annotation? SEG6_LOCAL_NH4 is
> a raw IPv4 address and handled as a struct in_addr in the kernel, but here
> it is typed as a native u32. This might cause YNL tools to silently
> byte-swap the address on little-endian architectures.
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3