* [PATCH net-next v3 0/6] netlink: add lwtunnel encap sub-message support to rt-route
@ 2026-09-30 1:50 Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 1/6] net: lwtunnel: change encap fill order Hangbin Liu
` (5 more replies)
0 siblings, 6 replies; 15+ messages in thread
From: Hangbin Liu @ 2026-09-30 1:50 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Donald Hunter
Cc: Hangbin Liu, netdev, linux-kernel, bpf, Hangbin Liu
This series adds YNL sub-message support for lwtunnel encap data in
the rt-route netlink family, and describes the tunnel-specific
attribute sets that were previously opaque binary blobs.
The kernel currently emits encap_type after the encap payload nest,
but YNL sub-message parsing needs the selector (encap_type) first to
dispatch on the correct attribute set. Patch 1 reorders the kernel
output, and patch 2 teaches the YNL C code generator to convert enum
selectors to their string form for sub-message dispatch.
Patches 3-6 extend the rt-route YAML spec.
Tested with ynl selftest and checked with following cmds
# modprobe ila
# modprobe xfrm_interface
# ip addr add 10.1.0.1/24 dev lo
# ip route add 10.1.0.0/24 dev lo encap mpls 100 via 10.1.0.254
# ip route add 10.2.0.0/24 dev lo encap ip id 1 dst 127.0.0.1 src 127.0.0.1
# ip route add 2001:db8:3::/64 dev lo encap ila 1:2:3:4 csum-mode no-action ident-type luid hook-type output
# ip route add 2001:db8:4::/64 dev lo encap ip6 id 1 dst 2001:db8::5 src 2001:db8::1 hoplimit 64
# ip route add 2001:db8:5::/64 dev lo encap seg6 mode inline segs 2001:db8::1
# ip route add 2001:db8:6::/65 dev lo encap seg6local action End flavors psp,next-csid lblen 32 nflen 16
# ip route add 2001:db8:7::/65 dev lo encap bpf in ob /tmp/kself/net/lib/xdp_dummy.bpf.o sec xdp
# ip route add 2001:db8:8::/64 dev lo encap rpl segs 2001:db8::1
# ip route add 2001:db8:9::/64 encap ioam6 trace prealloc type 0x800000 ns 0 size 4 dev lo
# ip route add 2001:db8:10::/64 dev lo encap xfrm if_id 100
# ip route show
10.1.0.0/24 encap mpls 100 via 10.1.0.254 dev lo
10.2.0.0/24 encap ip id 1 src 127.0.0.1 dst 127.0.0.1 ttl 0 tos 0 dev lo scope link
# ip -6 route show
2001:db8:3::/64 encap ila 1:2:3:4 csum-mode no-action ident-type luid hook-type output dev lo metric 1024 pref medium
2001:db8:4::/64 encap ip6 id 1 src 2001:db8::1 dst 2001:db8::5 hoplimit 64 tc 0 dev lo metric 1024 pref medium
2001:db8:5::/64 encap seg6 mode inline segs 2 [ 2001:db8::1 :: ] dev lo metric 1024 pref medium
2001:db8:6::/65 encap seg6local action End flavors psp,next-csid lblen 32 nflen 16 dev lo metric 1024 pref medium
2001:db8:7::/65 encap bpf in xdp_dummy.bpf.o:[xdp] dev lo metric 1024 pref medium
2001:db8:8::/64 encap rpl segs 1 [ 2001:db8::1 ] dev lo metric 1024 pref medium
2001:db8:9::/64 encap ioam6 freq 1/1 mode inline trace prealloc type 0x800000 ns 0 size 4 dev lo metric 1024 pref medium
2001:db8:10::/64 encap xfrm if_id 100 dev lo metric 1024 pref medium
# ./tools/net/ynl/pyynl/cli.py --family rt-route --dump getroute > /tmp/route_dump.json
All the result looks good.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
Changes in v3:
- patch 02: return local_vars and define new helpers is_enum_val and
get_enum_name (Jakub Kicinski)
- patch 03: alphabet order for header files in Makefile (Jakub Kicinski)
set byte-order for ila-attrs. ILA_ATTR_IDENTIFIER is not used, so no
need to set byte-order. (sashiko)
- patch 04: add multi-attr: true for geneve opts (sashiko)
- patch 05: remove lwt-bpf-prog from seg6 local, add a seg6 specific one
in patch 06 (sashiko)
- patch 06: add seg6-local-bpf and seg6-local-flv-ops. Set enum-as-flags
for seg6-local-flv-ops, set max-len for seg6-local-bpf-prog-name (sashiko)
- Link to v2: https://lore.kernel.org/r/20260920-ynl_rt_encap-v2-0-c664a3e726f6@kylinos.cn
Changes in v2:
- Patch 1: Check ops->fill_encap before setting encap_type_attr
- Patch 2: Get string in generated sub-message parser and check it before reference
- Patch 3-4: set byte-orders and max-len
- Patch 5: include lwtunnel.h
- Link to v1: https://lore.kernel.org/r/20260917-ynl_rt_encap-v1-0-fbbe6e680571@kylinos.cn
---
Hangbin Liu (6):
net: lwtunnel: change encap fill order
tools: ynl: convert enum selector to string for sub-message parsing
netlink: specs: rt-route: add lwtunnel encap sub-message support
netlink: specs: rt-route: describe lwtunnel IP options
netlink: specs: rt-route: describe lwt BPF program options
netlink: specs: rt-route: describe seg6-local attrs
Documentation/netlink/specs/rt-route.yaml | 446 +++++++++++++++++++++++++++++-
net/core/lwtunnel.c | 35 +--
tools/net/ynl/Makefile.deps | 9 +-
tools/net/ynl/pyynl/ynl_gen_c.py | 34 ++-
4 files changed, 500 insertions(+), 24 deletions(-)
---
base-commit: 806487df0088ff5f87890fadf95594d2afc00ff5
change-id: 20260908-ynl_rt_encap-3140103b368a
Best regards,
--
Hangbin Liu <liuhangbin@kylinos.cn>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH net-next v3 1/6] net: lwtunnel: change encap fill order
2026-09-30 1:50 [PATCH net-next v3 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
@ 2026-09-30 1:50 ` Hangbin Liu
2026-10-01 14:09 ` Ido Schimmel
2026-09-30 1:50 ` [PATCH net-next v3 2/6] tools: ynl: convert enum selector to string for sub-message parsing Hangbin Liu
` (4 subsequent siblings)
5 siblings, 1 reply; 15+ messages in thread
From: Hangbin Liu @ 2026-09-30 1:50 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Donald Hunter
Cc: Hangbin Liu, netdev, linux-kernel, bpf, Hangbin Liu
From: Hangbin Liu <liuhangbin@kylinos.cn>
I plan to add lwtunnel encap attributes to the YNL rt-route.yaml spec.
When decoding submessages, YNL expects to read the "selector" (encap-type)
first. Currently lwtunnel writes the encap payload first, which makes YNL
fail to parse the lwtunnel encap message.
Fixing this within YNL itself would be complicated. Instead, reorder the
netlink attributes in the kernel to output encap_type first.
This is a preparatory change for the upcoming rt-route spec updates.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
net/core/lwtunnel.c | 35 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/net/core/lwtunnel.c b/net/core/lwtunnel.c
index b01a395d9a96..8223c44f10c8 100644
--- a/net/core/lwtunnel.c
+++ b/net/core/lwtunnel.c
@@ -231,7 +231,7 @@ int lwtunnel_fill_encap(struct sk_buff *skb, struct lwtunnel_state *lwtstate,
{
const struct lwtunnel_encap_ops *ops;
struct nlattr *nest;
- int ret;
+ int ret = 0;
if (!lwtstate)
return 0;
@@ -240,30 +240,31 @@ int lwtunnel_fill_encap(struct sk_buff *skb, struct lwtunnel_state *lwtstate,
lwtstate->type > LWTUNNEL_ENCAP_MAX)
return 0;
- nest = nla_nest_start_noflag(skb, encap_attr);
- if (!nest)
- return -EMSGSIZE;
-
- ret = -EOPNOTSUPP;
rcu_read_lock();
+
ops = rcu_dereference(lwtun_encaps[lwtstate->type]);
- if (likely(ops && ops->fill_encap))
- ret = ops->fill_encap(skb, lwtstate);
- rcu_read_unlock();
+ if (unlikely(!ops || !ops->fill_encap))
+ goto unlock_out;
- if (ret)
- goto nla_put_failure;
- nla_nest_end(skb, nest);
ret = nla_put_u16(skb, encap_type_attr, lwtstate->type);
if (ret)
- goto nla_put_failure;
+ goto unlock_out;
- return 0;
+ nest = nla_nest_start_noflag(skb, encap_attr);
+ if (!nest) {
+ ret = -EMSGSIZE;
+ goto unlock_out;
+ }
-nla_put_failure:
- nla_nest_cancel(skb, nest);
+ ret = ops->fill_encap(skb, lwtstate);
+ if (ret)
+ nla_nest_cancel(skb, nest);
+ else
+ nla_nest_end(skb, nest);
- return (ret == -EOPNOTSUPP ? 0 : ret);
+unlock_out:
+ rcu_read_unlock();
+ return ret;
}
EXPORT_SYMBOL_GPL(lwtunnel_fill_encap);
--
2.55.0
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH net-next v3 2/6] tools: ynl: convert enum selector to string for sub-message parsing
2026-09-30 1:50 [PATCH net-next v3 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 1/6] net: lwtunnel: change encap fill order Hangbin Liu
@ 2026-09-30 1:50 ` Hangbin Liu
2026-10-01 1:51 ` sashiko-bot
2026-09-30 1:50 ` [PATCH net-next v3 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support Hangbin Liu
` (3 subsequent siblings)
5 siblings, 1 reply; 15+ messages in thread
From: Hangbin Liu @ 2026-09-30 1:50 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Donald Hunter
Cc: Hangbin Liu, netdev, linux-kernel, bpf, Hangbin Liu
From: Hangbin Liu <liuhangbin@kylinos.cn>
YNL sub-message parsing expects a string selector for strcmp(). So for
non-external enum selectors, convert the integer value to its string form
via the family's {enum}_str() helper. This enables correct decoding of
sub-messages keyed by enum values.
After the change, if there is no encap_type (e.g. previous ordering on
older kernels), the code will report "Sub-message key not set". If a new
encap_type is missing from the spec file in future kernel, the code will
return 0 gracefully rather than fail hard. With the subsequent rt-route
encap spec update, the newly generated code will look like:
if (!dst->_present.encap_type)
return ynl_submsg_failed(yarg, "encap", "encap-type");
encap_type_str = rt_route_encap_type_str(dst->encap_type);
if (!encap_type_str)
return 0;
if (rt_route_encap_data_parse(&parg, encap_type_str, attr))
return YNL_PARSE_CB_ERROR;
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
For sashiko:
1. For the extack error-walking path in ynl.c that doesn't handle
enum-keyed selectors. This series doesn't modify ynl.c, it changes
the code generator to emit the _str() conversion in generated parsing
code. The run time error-walking path is a separate concern.
Since rt-route encap is the first enum-keyed sub-message in the YNL
specs, this is a new limitation rather than a regression in existing
functionality. It can be addressed as a follow-up patch to ynl.c.
2. For the selector byte-order issue. This doesn't affect the current
series. The encap-type selector is type: u16 with no byte-order
specified (native order), so the raw value passed to _str() is already
host-order. nftables is in GENS_UNSUP today, so no in-tree generated
family hits this yet. We address this as a follow-up.
---
tools/net/ynl/pyynl/ynl_gen_c.py | 34 +++++++++++++++++++++++++++++-----
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index 15c79849c609..783242537fe4 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -951,13 +951,31 @@ class TypeSubMessage(TypeNest):
sel_var = f"_sel_{sel}"
else:
sel_var = f"{var}->{sel}"
- get_lines = [f'if (!{sel_var})',
- f'return ynl_submsg_failed(yarg, "{self.name}", "{selector}");',
- f"if ({self.nested_render_name}_parse(&parg, {sel_var}, attr))",
- "return YNL_PARSE_CB_ERROR;"]
+
+ local_vars = None
+
+ if self.selector.is_enum_val():
+ enum = self.family.consts[self.selector.get_enum_name()]
+ pres_var = f"{var}->_present.{sel}"
+ parse_sel = f"{sel}_str"
+ local_vars = [f'const char *{parse_sel};']
+
+ get_lines = [
+ f'if (!{pres_var})',
+ f'return ynl_submsg_failed(yarg, "{self.name}", "{selector}");',
+ f'{parse_sel} = {enum.render_name}_str({sel_var});',
+ f'if (!{parse_sel})',
+ 'return 0;']
+ else:
+ parse_sel = sel_var
+ get_lines = [f'if (!{parse_sel})',
+ f'return ynl_submsg_failed(yarg, "{self.name}", "{selector}");']
+
+ get_lines += [f"if ({self.nested_render_name}_parse(&parg, {parse_sel}, attr))",
+ "return YNL_PARSE_CB_ERROR;"]
init_lines = [f"parg.rsp_policy = &{self.nested_render_name}_nest;",
f"parg.data = &{var}->{self.c_name};"]
- return get_lines, init_lines, None
+ return get_lines, init_lines, local_vars
class Selector:
@@ -979,6 +997,12 @@ class Selector:
def is_external(self):
return self._external
+ def is_enum_val(self):
+ return self.get_enum_name() is not None
+
+ def get_enum_name(self):
+ return self.attr and self.attr.attr.get("enum")
+
class Struct:
def __init__(self, family, space_name, type_list=None, fixed_header=None,
--
2.55.0
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH net-next v3 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support
2026-09-30 1:50 [PATCH net-next v3 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 1/6] net: lwtunnel: change encap fill order Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 2/6] tools: ynl: convert enum selector to string for sub-message parsing Hangbin Liu
@ 2026-09-30 1:50 ` Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 4/6] netlink: specs: rt-route: describe lwtunnel IP options Hangbin Liu
` (2 subsequent siblings)
5 siblings, 0 replies; 15+ messages in thread
From: Hangbin Liu @ 2026-09-30 1:50 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Donald Hunter
Cc: Hangbin Liu, netdev, linux-kernel, bpf, Hangbin Liu
From: Hangbin Liu <liuhangbin@kylinos.cn>
Define encap-type enum (LWTUNNEL_ENCAP_*) and add encap-data sub-message
keyed by encap-type. Add tunnel attribute sets (mpls, ip, ila, ip6, seg6,
bpf, seg6-local, rpl, ioam6, xfrm). This spec update depends on the kernel
side encap-type/data reorder patch.
Keep some nested option attributes as binary in this patch to simplify
review; they will be converted in follow-up patches.
Also add the Makefile to include uapi headers. Note the lwtunnel.h
is guarded by _UAPI_LWTUNNEL_H_.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
Documentation/netlink/specs/rt-route.yaml | 287 +++++++++++++++++++++++++++++-
tools/net/ynl/Makefile.deps | 9 +-
2 files changed, 294 insertions(+), 2 deletions(-)
diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index 253037ea5176..dc842a786794 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -99,6 +99,58 @@ definitions:
name: ra-withdrawn
doc: A Router Advertisement withdrew the route with a zero
lifetime.
+ -
+ name: encap-type
+ type: enum
+ name-prefix: lwtunnel-encap-
+ enum-name:
+ entries:
+ - none
+ - mpls
+ - ip
+ - ila
+ - ip6
+ - seg6
+ - bpf
+ - seg6-local
+ - rpl
+ - ioam6
+ - xfrm
+
+sub-messages:
+ -
+ name: encap-data
+ formats:
+ -
+ value: mpls
+ attribute-set: mpls-iptunnel
+ -
+ value: ip
+ attribute-set: lwtunnel-ip
+ -
+ value: ila
+ attribute-set: ila-attrs
+ -
+ value: ip6
+ attribute-set: lwtunnel-ip6
+ -
+ value: seg6
+ attribute-set: seg6-iptunnel
+ -
+ value: bpf
+ attribute-set: lwt-bpf
+ -
+ value: seg6-local
+ attribute-set: seg6-local
+ -
+ value: rpl
+ attribute-set: rpl-iptunnel
+ -
+ value: ioam6
+ attribute-set: ioam6-iptunnel
+ -
+ value: xfrm
+ attribute-set: lwt-xfrm
attribute-sets:
-
@@ -174,9 +226,12 @@ attribute-sets:
-
name: encap-type
type: u16
+ enum: encap-type
-
name: encap
- type: binary # tunnel specific nest
+ type: sub-message
+ sub-message: encap-data
+ selector: encap-type
-
name: expires
type: u32
@@ -277,6 +332,236 @@ attribute-sets:
-
name: fastopen-no-cookie
type: u32
+ -
+ name: mpls-iptunnel
+ name-prefix: mpls-iptunnel-
+ header: linux/mpls_iptunnel.h
+ attributes:
+ -
+ name: dst
+ type: binary
+ -
+ name: ttl
+ type: u8
+ -
+ name: lwtunnel-ip
+ name-prefix: lwtunnel-ip-
+ header: linux/lwtunnel.h
+ attributes:
+ -
+ name: id
+ type: u64
+ byte-order: big-endian
+ -
+ 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
+ byte-order: big-endian
+ -
+ name: pad
+ type: pad
+ -
+ name: opts
+ type: binary # lwtunnel ip nest options
+ -
+ name: ila-attrs
+ name-prefix: ila-attr-
+ header: linux/ila.h
+ attributes:
+ -
+ name: locator
+ type: u64
+ byte-order: big-endian
+ -
+ name: identifier
+ type: u64
+ -
+ name: locator-match
+ type: u64
+ byte-order: big-endian
+ -
+ name: ifindex
+ type: s32
+ -
+ name: dir
+ type: u32
+ -
+ name: pad
+ type: pad
+ -
+ name: csum-mode
+ type: u8
+ -
+ name: ident-type
+ type: u8
+ -
+ name: hook-type
+ type: u8
+ -
+ name: lwtunnel-ip6
+ name-prefix: lwtunnel-ip6-
+ header: linux/lwtunnel.h
+ attributes:
+ -
+ name: id
+ type: u64
+ byte-order: big-endian
+ -
+ name: dst
+ type: binary
+ display-hint: ipv6
+ -
+ name: src
+ type: binary
+ display-hint: ipv6
+ -
+ name: hoplimit
+ type: u8
+ -
+ name: tc
+ type: u8
+ -
+ name: flags
+ type: u16
+ byte-order: big-endian
+ -
+ name: pad
+ type: pad
+ -
+ name: opts
+ type: binary # lwtunnel ip nest options
+ -
+ name: seg6-iptunnel
+ name-prefix: seg6-iptunnel-
+ header: linux/seg6_iptunnel.h
+ attributes:
+ -
+ name: srh
+ type: binary
+ -
+ name: src
+ type: binary
+ display-hint: ipv6
+ -
+ name: table
+ type: u32
+ -
+ name: lwt-bpf
+ name-prefix: lwt-bpf-
+ header: linux/lwtunnel.h
+ attributes:
+ -
+ name: in
+ type: binary # bpf prog
+ -
+ name: out
+ type: binary
+ -
+ name: xmit
+ type: binary
+ -
+ name: xmit-headroom
+ type: u32
+ -
+ name: seg6-local
+ name-prefix: seg6-local-
+ header: linux/seg6_local.h
+ attributes:
+ -
+ name: action
+ type: u32
+ -
+ name: srh
+ type: binary
+ -
+ name: table
+ type: u32
+ -
+ name: nh4
+ type: u32
+ byte-order: big-endian
+ display-hint: ipv4
+ -
+ name: nh6
+ type: binary
+ display-hint: ipv6
+ -
+ name: iif
+ type: u32
+ -
+ name: oif
+ type: u32
+ -
+ name: bpf
+ type: binary
+ -
+ name: vrftable
+ type: u32
+ -
+ name: counters
+ type: binary
+ -
+ name: flavors
+ type: binary
+ -
+ name: rpl-iptunnel
+ name-prefix: rpl-iptunnel-
+ header: linux/rpl_iptunnel.h
+ attributes:
+ -
+ name: srh
+ type: binary
+ -
+ name: ioam6-iptunnel
+ name-prefix: ioam6-iptunnel-
+ header: linux/ioam6_iptunnel.h
+ attributes:
+ -
+ name: mode
+ type: u8
+ -
+ name: dst
+ type: binary
+ display-hint: ipv6
+ -
+ name: trace
+ type: binary
+ -
+ name: freq-k
+ type: u32
+ -
+ name: freq-n
+ type: u32
+ -
+ name: src
+ type: binary
+ display-hint: ipv6
+ -
+ name: lwt-xfrm
+ name-prefix: lwt-xfrm-
+ header: linux/lwtunnel.h
+ attributes:
+ -
+ name: if-id
+ type: u32
+ -
+ name: link
+ type: u32
operations:
enum-model: directional
diff --git a/tools/net/ynl/Makefile.deps b/tools/net/ynl/Makefile.deps
index 1e746e25e2bc..3eee34e0efcf 100644
--- a/tools/net/ynl/Makefile.deps
+++ b/tools/net/ynl/Makefile.deps
@@ -45,7 +45,14 @@ CFLAGS_rt-link:=$(call get_hdr_inc,__LINUX_RTNETLINK_H,rtnetlink.h) \
$(call get_hdr_inc,_LINUX_IF_LINK_H,if_link.h)
CFLAGS_rt-neigh:=$(call get_hdr_inc,__LINUX_RTNETLINK_H,rtnetlink.h) \
$(call get_hdr_inc,__LINUX_NEIGHBOUR_H,neighbour.h)
-CFLAGS_rt-route:=$(call get_hdr_inc,__LINUX_RTNETLINK_H,rtnetlink.h)
+CFLAGS_rt-route:=$(call get_hdr_inc,_LINUX_ILA_H,ila.h) \
+ $(call get_hdr_inc,_LINUX_IOAM6_IPTUNNEL_H,ioam6_iptunnel.h) \
+ $(call get_hdr_inc,_LINUX_MPLS_IPTUNNEL_H,mpls_iptunnel.h) \
+ $(call get_hdr_inc,_LINUX_RPL_IPTUNNEL_H,rpl_iptunnel.h) \
+ $(call get_hdr_inc,__LINUX_RTNETLINK_H,rtnetlink.h) \
+ $(call get_hdr_inc,_LINUX_SEG6_IPTUNNEL_H,seg6_iptunnel.h) \
+ $(call get_hdr_inc,_LINUX_SEG6_LOCAL_H,seg6_local.h) \
+ $(call get_hdr_inc,_LWTUNNEL_H_,lwtunnel.h)
CFLAGS_rt-rule:=$(call get_hdr_inc,__LINUX_FIB_RULES_H,fib_rules.h)
CFLAGS_tc:= $(call get_hdr_inc,__LINUX_RTNETLINK_H,rtnetlink.h) \
$(call get_hdr_inc,__LINUX_PKT_SCHED_H,pkt_sched.h) \
--
2.55.0
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH net-next v3 4/6] netlink: specs: rt-route: describe lwtunnel IP options
2026-09-30 1:50 [PATCH net-next v3 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
` (2 preceding siblings ...)
2026-09-30 1:50 ` [PATCH net-next v3 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support Hangbin Liu
@ 2026-09-30 1:50 ` Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 5/6] netlink: specs: rt-route: describe lwt BPF program options Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 6/6] netlink: specs: rt-route: describe seg6-local attrs Hangbin Liu
5 siblings, 0 replies; 15+ messages in thread
From: Hangbin Liu @ 2026-09-30 1:50 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Donald Hunter
Cc: Hangbin Liu, netdev, linux-kernel, bpf, Hangbin Liu
From: Hangbin Liu <liuhangbin@kylinos.cn>
Replace binary opts in lwtunnel-ip and lwtunnel-ip6 with a nested
lwtunnel-ip-opts set. Add attribute sets for geneve, vxlan, and erspan
IP options to match linux/lwtunnel.h.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
Documentation/netlink/specs/rt-route.yaml | 63 ++++++++++++++++++++++++++++++-
1 file changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index dc842a786794..7649797602eb 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -377,7 +377,8 @@ attribute-sets:
type: pad
-
name: opts
- type: binary # lwtunnel ip nest options
+ type: nest
+ nested-attributes: lwtunnel-ip-opts
-
name: ila-attrs
name-prefix: ila-attr-
@@ -444,7 +445,8 @@ attribute-sets:
type: pad
-
name: opts
- type: binary # lwtunnel ip nest options
+ type: nest
+ nested-attributes: lwtunnel-ip-opts
-
name: seg6-iptunnel
name-prefix: seg6-iptunnel-
@@ -562,6 +564,63 @@ attribute-sets:
-
name: link
type: u32
+ -
+ name: lwtunnel-ip-opts
+ name-prefix: lwtunnel-ip-opts-
+ attributes:
+ -
+ name: geneve
+ type: nest
+ nested-attributes: lwtunnel-ip-opt-geneve
+ multi-attr: true
+ -
+ name: vxlan
+ type: nest
+ nested-attributes: lwtunnel-ip-opt-vxlan
+ -
+ name: erspan
+ type: nest
+ nested-attributes: lwtunnel-ip-opt-erspan
+ -
+ name: lwtunnel-ip-opt-geneve
+ name-prefix: lwtunnel-ip-opt-geneve-
+ attributes:
+ -
+ name: class
+ type: u16
+ byte-order: big-endian
+ -
+ name: type
+ type: u8
+ -
+ name: data
+ type: binary
+ checks:
+ max-len: 127
+ -
+ name: lwtunnel-ip-opt-vxlan
+ name-prefix: lwtunnel-ip-opt-vxlan-
+ attributes:
+ -
+ name: gbp
+ type: u32
+ -
+ name: lwtunnel-ip-opt-erspan
+ name-prefix: lwtunnel-ip-opt-erspan-
+ attributes:
+ -
+ name: ver
+ type: u8
+ -
+ name: index
+ type: u32
+ byte-order: big-endian
+ -
+ name: dir
+ type: u8
+ -
+ name: hwid
+ type: u8
operations:
enum-model: directional
--
2.55.0
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH net-next v3 5/6] netlink: specs: rt-route: describe lwt BPF program options
2026-09-30 1:50 [PATCH net-next v3 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
` (3 preceding siblings ...)
2026-09-30 1:50 ` [PATCH net-next v3 4/6] netlink: specs: rt-route: describe lwtunnel IP options Hangbin Liu
@ 2026-09-30 1:50 ` Hangbin Liu
2026-10-01 1:51 ` sashiko-bot
2026-09-30 1:50 ` [PATCH net-next v3 6/6] netlink: specs: rt-route: describe seg6-local attrs Hangbin Liu
5 siblings, 1 reply; 15+ messages in thread
From: Hangbin Liu @ 2026-09-30 1:50 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Donald Hunter
Cc: Hangbin Liu, netdev, linux-kernel, bpf, Hangbin Liu
From: Hangbin Liu <liuhangbin@kylinos.cn>
Replace binary BPF attributes with a nested lwt-bpf-prog to support
lwt bpf prog options.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
Documentation/netlink/specs/rt-route.yaml | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index 7649797602eb..afec0375661f 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -469,13 +469,16 @@ attribute-sets:
attributes:
-
name: in
- type: binary # bpf prog
+ type: nest
+ nested-attributes: lwt-bpf-prog
-
name: out
- type: binary
+ type: nest
+ nested-attributes: lwt-bpf-prog
-
name: xmit
- type: binary
+ type: nest
+ nested-attributes: lwt-bpf-prog
-
name: xmit-headroom
type: u32
@@ -621,6 +624,16 @@ attribute-sets:
-
name: hwid
type: u8
+ -
+ name: lwt-bpf-prog
+ name-prefix: lwt-bpf-prog-
+ attributes:
+ -
+ name: fd
+ type: u32
+ -
+ name: name
+ type: string
operations:
enum-model: directional
--
2.55.0
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH net-next v3 6/6] netlink: specs: rt-route: describe seg6-local attrs
2026-09-30 1:50 [PATCH net-next v3 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
` (4 preceding siblings ...)
2026-09-30 1:50 ` [PATCH net-next v3 5/6] netlink: specs: rt-route: describe lwt BPF program options Hangbin Liu
@ 2026-09-30 1:50 ` Hangbin Liu
2026-10-01 1:51 ` sashiko-bot
5 siblings, 1 reply; 15+ messages in thread
From: Hangbin Liu @ 2026-09-30 1:50 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Donald Hunter
Cc: Hangbin Liu, netdev, linux-kernel, bpf, Hangbin Liu
From: Hangbin Liu <liuhangbin@kylinos.cn>
Add SEG6 local actions enums, seg6-local-flv-ops flags.
Replace binary bpf/counters/flavors in seg6-local with
nested seg6-local-bpf, seg6-local-cnt and seg6-local-flv.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
Documentation/netlink/specs/rt-route.yaml | 93 ++++++++++++++++++++++++++++++-
1 file changed, 90 insertions(+), 3 deletions(-)
diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index afec0375661f..0260fca398d2 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -116,6 +116,45 @@ definitions:
- rpl
- ioam6
- xfrm
+ -
+ name: seg6-local-actions
+ type: enum
+ name-prefix: seg6-local-action-
+ enum-name:
+ entries:
+ - unspec
+ - end
+ - end-x
+ - end-t
+ - end-dx2
+ - end-dx6
+ - end-dx4
+ - end-dt6
+ - end-dt4
+ - end-b6
+ - end-b6-encap
+ - end-bm
+ - end-s
+ - end-as
+ - end-am
+ - end-bpf
+ - end-dt46
+ -
+ name: seg6-local-flv-ops
+ type: flags
+ name-prefix: seg6_local_flv_op-
+ enum-name:
+ entries:
+ -
+ name: unspec
+ -
+ name: psp
+ -
+ name: usp
+ -
+ name: usd
+ -
+ name: next-csid
sub-messages:
-
@@ -490,6 +529,7 @@ attribute-sets:
-
name: action
type: u32
+ enum: seg6-local-actions
-
name: srh
type: binary
@@ -513,16 +553,19 @@ attribute-sets:
type: u32
-
name: bpf
- type: binary
+ type: nest
+ nested-attributes: seg6-local-bpf
-
name: vrftable
type: u32
-
name: counters
- type: binary
+ type: nest
+ nested-attributes: seg6-local-cnt
-
name: flavors
- type: binary
+ type: nest
+ nested-attributes: seg6-local-flv
-
name: rpl-iptunnel
name-prefix: rpl-iptunnel-
@@ -634,6 +677,50 @@ attribute-sets:
-
name: name
type: string
+ -
+ name: seg6-local-bpf
+ name-prefix: seg6-local-bpf-
+ attr-max-name: seg6-local-bpf-prog-max
+ attributes:
+ -
+ name: prog
+ type: u32
+ -
+ name: prog-name
+ type: string
+ checks:
+ max-len: 256
+ -
+ name: seg6-local-cnt
+ name-prefix: seg6-local-cnt-
+ attributes:
+ -
+ name: pad
+ type: pad
+ -
+ name: packets
+ type: u64
+ -
+ name: bytes
+ type: u64
+ -
+ name: errors
+ type: u64
+ -
+ name: seg6-local-flv
+ name-prefix: seg6-local-flv-
+ attributes:
+ -
+ name: operation
+ type: u32
+ enum: seg6-local-flv-ops
+ enum-as-flags: true
+ -
+ name: lcblock-bits
+ type: u8
+ -
+ name: lcnode-fn-bits
+ type: u8
operations:
enum-model: directional
--
2.55.0
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH net-next v3 6/6] netlink: specs: rt-route: describe seg6-local attrs
2026-09-30 1:50 ` [PATCH net-next v3 6/6] netlink: specs: rt-route: describe seg6-local attrs Hangbin Liu
@ 2026-10-01 1:51 ` sashiko-bot
2026-10-03 6:17 ` Hangbin Liu
0 siblings, 1 reply; 15+ messages in thread
From: sashiko-bot @ 2026-10-01 1:51 UTC (permalink / raw)
To: Hangbin Liu; +Cc: bpf
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] netlink: incorrect type: flags causes uAPI mismatch for seg6-local-flv-ops
- [Low] netlink: yaml naming convention violation in seg6-local-flv-ops name-prefix
- [Low] netlink: missing doc properties on new major yaml spec additions
--
commit 1d8d137d71e90b2ea51b5a3ae23d03831ee06b0b
Author: Hangbin Liu <liuhangbin@kylinos.cn>
netlink: specs: rt-route: describe seg6-local attrs
This commit adds SEG6 local actions enums and seg6-local-flv-ops flags to the
rt-route Netlink specification. It also replaces binary attributes with nested
seg6-local-bpf, seg6-local-cnt, and seg6-local-flv definitions.
> diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> index afec0375661f5..0260fca398d2c 100644
> --- a/Documentation/netlink/specs/rt-route.yaml
> +++ b/Documentation/netlink/specs/rt-route.yaml
> @@ -116,6 +116,45 @@ definitions:
> - rpl
> - ioam6
> - xfrm
> + -
> + name: seg6-local-actions
> + type: enum
[Severity: Low]
Does this new major property need a doc field? The Netlink subsystem
guidelines recommend that each major property should carry a doc entry to
explain its purpose.
[ ... ]
> + -
> + name: seg6-local-flv-ops
> + type: flags
> + name-prefix: seg6_local_flv_op-
[Severity: High]
Can using type: flags here cause a uAPI mismatch with the kernel?
The kernel uAPI defines these operations as sequential values (for example,
SEG6_LOCAL_FLV_OP_USD is 3). When type: flags is used, the YNL code
generator will emit bitmasks (1, 2, 4, 8), resulting in
SEG6_LOCAL_FLV_OP_USD being incorrectly defined as 8 in the generated
headers.
Would it be safer to use type: enum to ensure the generated values match
the existing kernel constants?
[Severity: Low]
Also, could the name-prefix use dashes instead of underscores? The naming
convention for YAML specs specifies that names should contain dashes, as
the code generator handles converting them to underscores for the C code.
[Severity: Low]
Additionally, should seg6-local-flv-ops include a doc property?
[ ... ]
> @@ -634,6 +677,50 @@ attribute-sets:
> -
> name: name
> type: string
> + -
> + name: seg6-local-bpf
> + name-prefix: seg6-local-bpf-
[Severity: Low]
Would it be helpful to include a doc property for this attribute set? The
guidelines mention that new major properties, such as seg6-local-bpf,
seg6-local-cnt, and seg6-local-flv, should carry documentation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260930-ynl_rt_encap-v3-0-4106c21b9ee7@kylinos.cn?part=6
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next v3 2/6] tools: ynl: convert enum selector to string for sub-message parsing
2026-09-30 1:50 ` [PATCH net-next v3 2/6] tools: ynl: convert enum selector to string for sub-message parsing Hangbin Liu
@ 2026-10-01 1:51 ` sashiko-bot
2026-10-03 6:23 ` Hangbin Liu
0 siblings, 1 reply; 15+ messages in thread
From: sashiko-bot @ 2026-10-01 1:51 UTC (permalink / raw)
To: Hangbin Liu; +Cc: bpf
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] ynl: early return 0 aborts entire parsing loop on unknown sub-message
- [Medium] ynl: invalid C code generated for external enum selectors
--
commit f2c434cd3f008807f1723585dcbfd634aa3f28b7
Author: Hangbin Liu <liuhangbin@kylinos.cn>
tools: ynl: convert enum selector to string for sub-message parsing
YNL sub-message parsing expects a string selector for strcmp(). So for
non-external enum selectors, convert the integer value to its string form
via the family's {enum}_str() helper. This enables correct decoding of
sub-messages keyed by enum values.
> diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
> index 15c79849c6096..783242537fe48 100755
> --- a/tools/net/ynl/pyynl/ynl_gen_c.py
> +++ b/tools/net/ynl/pyynl/ynl_gen_c.py
> @@ -951,13 +951,31 @@ class TypeSubMessage(TypeNest):
> sel_var = f"_sel_{sel}"
> else:
> sel_var = f"{var}->{sel}"
> - get_lines = [f'if (!{sel_var})',
> - f'return ynl_submsg_failed(yarg, "{self.name}", "{selector}");',
> - f"if ({self.nested_render_name}_parse(&parg, {sel_var}, attr))",
> - "return YNL_PARSE_CB_ERROR;"]
> +
> + local_vars = None
> +
> + if self.selector.is_enum_val():
^^^^
[Severity: Medium]
Will this generate invalid C code for external enum selectors?
The condition doesn't check if the selector is external. If a YAML spec
defines a sub-message with an external enum selector, it appears this will
generate a non-existent structure member access for the presence variable:
pres_var = f"{var}->_present.{sel}"
and try to pass the string pointer to the enum string helper, which expects
an integer. Should this check include `and not self.selector.is_external()`?
> + enum = self.family.consts[self.selector.get_enum_name()]
> + pres_var = f"{var}->_present.{sel}"
> + parse_sel = f"{sel}_str"
> + local_vars = [f'const char *{parse_sel};']
> +
> + get_lines = [
> + f'if (!{pres_var})',
> + f'return ynl_submsg_failed(yarg, "{self.name}", "{selector}");',
> + f'{parse_sel} = {enum.render_name}_str({sel_var});',
> + f'if (!{parse_sel})',
> + 'return 0;']
^^^^
[Severity: High]
Does returning 0 here abort the entire parsing loop?
If a generated YNL parser encounters an unrecognized sub-message enum
selector (for example, sent by a newer kernel), it looks like `return 0;`
executes directly inside the attribute loop of the parsing function.
This would silently abort processing the remainder of the Netlink message and
drop all trailing attributes without returning an error. Is it possible to
skip the attribute and continue parsing instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260930-ynl_rt_encap-v3-0-4106c21b9ee7@kylinos.cn?part=2
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next v3 5/6] netlink: specs: rt-route: describe lwt BPF program options
2026-09-30 1:50 ` [PATCH net-next v3 5/6] netlink: specs: rt-route: describe lwt BPF program options Hangbin Liu
@ 2026-10-01 1:51 ` sashiko-bot
2026-10-03 6:09 ` Hangbin Liu
0 siblings, 1 reply; 15+ messages in thread
From: sashiko-bot @ 2026-10-01 1:51 UTC (permalink / raw)
To: Hangbin Liu; +Cc: bpf
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] netlink: missing max-len validation constraint for string attribute
--
commit f56da32d0f53d2458e2f20c65435e7f6e11b64a4
Author: Hangbin Liu <liuhangbin@kylinos.cn>
netlink: specs: rt-route: describe lwt BPF program options
This patch replaces binary BPF attributes with a nested lwt-bpf-prog to
support lwt bpf prog options in the rt-route netlink specification.
> diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> index 7649797602eb7..afec0375661f5 100644
> --- a/Documentation/netlink/specs/rt-route.yaml
> +++ b/Documentation/netlink/specs/rt-route.yaml
[ ... ]
> @@ -621,6 +624,16 @@ attribute-sets:
> -
> name: hwid
> type: u8
> + -
> + name: lwt-bpf-prog
> + name-prefix: lwt-bpf-prog-
> + attributes:
> + -
> + name: fd
> + type: u32
> + -
> + name: name
> + type: string
[Severity: Low]
Does this string attribute need a maximum length validation constraint?
The kernel's LWT_BPF_PROG_NAME policy restricts the length to MAX_PROG_NAME
(which is 256). For netlink string specifications, this usually means adding
a checks section with max-len: 255.
Without this declarative constraint, the generated userspace tooling will not
restrict the string length prior to constructing the netlink message, forcing
the kernel to reject over-sized strings. This bypasses client-side validation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260930-ynl_rt_encap-v3-0-4106c21b9ee7@kylinos.cn?part=5
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next v3 1/6] net: lwtunnel: change encap fill order
2026-09-30 1:50 ` [PATCH net-next v3 1/6] net: lwtunnel: change encap fill order Hangbin Liu
@ 2026-10-01 14:09 ` Ido Schimmel
0 siblings, 0 replies; 15+ messages in thread
From: Ido Schimmel @ 2026-10-01 14:09 UTC (permalink / raw)
To: Hangbin Liu
Cc: David Ahern, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Donald Hunter, netdev, linux-kernel,
bpf, Hangbin Liu
On Wed, Sep 30, 2026 at 09:50:52AM +0800, Hangbin Liu wrote:
> From: Hangbin Liu <liuhangbin@kylinos.cn>
>
> I plan to add lwtunnel encap attributes to the YNL rt-route.yaml spec.
> When decoding submessages, YNL expects to read the "selector" (encap-type)
> first. Currently lwtunnel writes the encap payload first, which makes YNL
> fail to parse the lwtunnel encap message.
>
> Fixing this within YNL itself would be complicated. Instead, reorder the
> netlink attributes in the kernel to output encap_type first.
>
> This is a preparatory change for the upcoming rt-route spec updates.
>
> Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
In case the bots will complain: It's OK not to trim the type attribute
upon fill_encap() failure given that the callers cancel the entire
message.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next v3 5/6] netlink: specs: rt-route: describe lwt BPF program options
2026-10-01 1:51 ` sashiko-bot
@ 2026-10-03 6:09 ` Hangbin Liu
0 siblings, 0 replies; 15+ messages in thread
From: Hangbin Liu @ 2026-10-03 6:09 UTC (permalink / raw)
To: sashiko-reviews; +Cc: bpf
On Thu, Oct 01, 2026 at 01:51:34AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] netlink: missing max-len validation constraint for string attribute
> --
>
> commit f56da32d0f53d2458e2f20c65435e7f6e11b64a4
> Author: Hangbin Liu <liuhangbin@kylinos.cn>
>
> netlink: specs: rt-route: describe lwt BPF program options
>
> This patch replaces binary BPF attributes with a nested lwt-bpf-prog to
> support lwt bpf prog options in the rt-route netlink specification.
>
> > diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> > index 7649797602eb7..afec0375661f5 100644
> > --- a/Documentation/netlink/specs/rt-route.yaml
> > +++ b/Documentation/netlink/specs/rt-route.yaml
> [ ... ]
> > @@ -621,6 +624,16 @@ attribute-sets:
> > -
> > name: hwid
> > type: u8
> > + -
> > + name: lwt-bpf-prog
> > + name-prefix: lwt-bpf-prog-
> > + attributes:
> > + -
> > + name: fd
> > + type: u32
> > + -
> > + name: name
> > + type: string
>
> [Severity: Low]
> Does this string attribute need a maximum length validation constraint?
>
> The kernel's LWT_BPF_PROG_NAME policy restricts the length to MAX_PROG_NAME
> (which is 256). For netlink string specifications, this usually means adding
> a checks section with max-len: 255.
Why we should use 255 here? The bpf_encap_nlsize() alloc size
nla_total_size(MAX_PROG_NAME).
Hangbin
>
> Without this declarative constraint, the generated userspace tooling will not
> restrict the string length prior to constructing the netlink message, forcing
> the kernel to reject over-sized strings. This bypasses client-side validation.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260930-ynl_rt_encap-v3-0-4106c21b9ee7@kylinos.cn?part=5
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next v3 6/6] netlink: specs: rt-route: describe seg6-local attrs
2026-10-01 1:51 ` sashiko-bot
@ 2026-10-03 6:17 ` Hangbin Liu
0 siblings, 0 replies; 15+ messages in thread
From: Hangbin Liu @ 2026-10-03 6:17 UTC (permalink / raw)
To: sashiko-reviews; +Cc: bpf
On Thu, Oct 01, 2026 at 01:51:33AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] netlink: incorrect type: flags causes uAPI mismatch for seg6-local-flv-ops
> - [Low] netlink: yaml naming convention violation in seg6-local-flv-ops name-prefix
> - [Low] netlink: missing doc properties on new major yaml spec additions
> --
>
> commit 1d8d137d71e90b2ea51b5a3ae23d03831ee06b0b
> Author: Hangbin Liu <liuhangbin@kylinos.cn>
>
> netlink: specs: rt-route: describe seg6-local attrs
>
> This commit adds SEG6 local actions enums and seg6-local-flv-ops flags to the
> rt-route Netlink specification. It also replaces binary attributes with nested
> seg6-local-bpf, seg6-local-cnt, and seg6-local-flv definitions.
>
> > diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> > index afec0375661f5..0260fca398d2c 100644
> > --- a/Documentation/netlink/specs/rt-route.yaml
> > +++ b/Documentation/netlink/specs/rt-route.yaml
> > @@ -116,6 +116,45 @@ definitions:
> > - rpl
> > - ioam6
> > - xfrm
> > + -
> > + name: seg6-local-actions
> > + type: enum
>
> [Severity: Low]
> Does this new major property need a doc field? The Netlink subsystem
> guidelines recommend that each major property should carry a doc entry to
> explain its purpose.
>
> [ ... ]
>
> > + -
> > + name: seg6-local-flv-ops
> > + type: flags
> > + name-prefix: seg6_local_flv_op-
>
> [Severity: High]
> Can using type: flags here cause a uAPI mismatch with the kernel?
Right, I forgot the change the type and name prefix.
>
> The kernel uAPI defines these operations as sequential values (for example,
> SEG6_LOCAL_FLV_OP_USD is 3). When type: flags is used, the YNL code
> generator will emit bitmasks (1, 2, 4, 8), resulting in
> SEG6_LOCAL_FLV_OP_USD being incorrectly defined as 8 in the generated
> headers.
>
> Would it be safer to use type: enum to ensure the generated values match
> the existing kernel constants?
>
> [Severity: Low]
> Also, could the name-prefix use dashes instead of underscores? The naming
> convention for YAML specs specifies that names should contain dashes, as
> the code generator handles converting them to underscores for the C code.
Yes, I will fix it.
Thanks
Hangbin
>
> [Severity: Low]
> Additionally, should seg6-local-flv-ops include a doc property?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next v3 2/6] tools: ynl: convert enum selector to string for sub-message parsing
2026-10-01 1:51 ` sashiko-bot
@ 2026-10-03 6:23 ` Hangbin Liu
2026-10-05 22:33 ` Jakub Kicinski
0 siblings, 1 reply; 15+ messages in thread
From: Hangbin Liu @ 2026-10-03 6:23 UTC (permalink / raw)
To: sashiko-reviews; +Cc: bpf, netdev
On Thu, Oct 01, 2026 at 01:51:34AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] ynl: early return 0 aborts entire parsing loop on unknown sub-message
> - [Medium] ynl: invalid C code generated for external enum selectors
> --
>
> commit f2c434cd3f008807f1723585dcbfd634aa3f28b7
> Author: Hangbin Liu <liuhangbin@kylinos.cn>
>
> tools: ynl: convert enum selector to string for sub-message parsing
>
> YNL sub-message parsing expects a string selector for strcmp(). So for
> non-external enum selectors, convert the integer value to its string form
> via the family's {enum}_str() helper. This enables correct decoding of
> sub-messages keyed by enum values.
>
> > diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
> > index 15c79849c6096..783242537fe48 100755
> > --- a/tools/net/ynl/pyynl/ynl_gen_c.py
> > +++ b/tools/net/ynl/pyynl/ynl_gen_c.py
> > @@ -951,13 +951,31 @@ class TypeSubMessage(TypeNest):
> > sel_var = f"_sel_{sel}"
> > else:
> > sel_var = f"{var}->{sel}"
> > - get_lines = [f'if (!{sel_var})',
> > - f'return ynl_submsg_failed(yarg, "{self.name}", "{selector}");',
> > - f"if ({self.nested_render_name}_parse(&parg, {sel_var}, attr))",
> > - "return YNL_PARSE_CB_ERROR;"]
> > +
> > + local_vars = None
> > +
> > + if self.selector.is_enum_val():
> ^^^^
>
> [Severity: Medium]
> Will this generate invalid C code for external enum selectors?
>
> The condition doesn't check if the selector is external. If a YAML spec
> defines a sub-message with an external enum selector, it appears this will
> generate a non-existent structure member access for the presence variable:
>
> pres_var = f"{var}->_present.{sel}"
>
> and try to pass the string pointer to the enum string helper, which expects
> an integer. Should this check include `and not self.selector.is_external()`?
OK...
>
> > + enum = self.family.consts[self.selector.get_enum_name()]
> > + pres_var = f"{var}->_present.{sel}"
> > + parse_sel = f"{sel}_str"
> > + local_vars = [f'const char *{parse_sel};']
> > +
> > + get_lines = [
> > + f'if (!{pres_var})',
> > + f'return ynl_submsg_failed(yarg, "{self.name}", "{selector}");',
> > + f'{parse_sel} = {enum.render_name}_str({sel_var});',
> > + f'if (!{parse_sel})',
> > + 'return 0;']
> ^^^^
>
> [Severity: High]
> Does returning 0 here abort the entire parsing loop?
>
> If a generated YNL parser encounters an unrecognized sub-message enum
> selector (for example, sent by a newer kernel), it looks like `return 0;`
> executes directly inside the attribute loop of the parsing function.
>
> This would silently abort processing the remainder of the Netlink message and
> drop all trailing attributes without returning an error. Is it possible to
> skip the attribute and continue parsing instead?
OK, I will use continue then.
Thanks
Hangbin
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next v3 2/6] tools: ynl: convert enum selector to string for sub-message parsing
2026-10-03 6:23 ` Hangbin Liu
@ 2026-10-05 22:33 ` Jakub Kicinski
0 siblings, 0 replies; 15+ messages in thread
From: Jakub Kicinski @ 2026-10-05 22:33 UTC (permalink / raw)
To: Hangbin Liu; +Cc: sashiko-reviews, bpf, netdev
On Sat, 3 Oct 2026 14:23:53 +0800 Hangbin Liu wrote:
> > [Severity: High]
> > Does returning 0 here abort the entire parsing loop?
> >
> > If a generated YNL parser encounters an unrecognized sub-message enum
> > selector (for example, sent by a newer kernel), it looks like `return 0;`
> > executes directly inside the attribute loop of the parsing function.
> >
> > This would silently abort processing the remainder of the Netlink message and
> > drop all trailing attributes without returning an error. Is it possible to
> > skip the attribute and continue parsing instead?
>
> OK, I will use continue then.
Ehm, probably do something like:
return ynl_submsg_failed(yarg, self.name, "enum-lookup-failed")
? AFAICT if string lookup fails we'd error out.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2026-10-05 22:33 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-30 1:50 [PATCH net-next v3 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 1/6] net: lwtunnel: change encap fill order Hangbin Liu
2026-10-01 14:09 ` Ido Schimmel
2026-09-30 1:50 ` [PATCH net-next v3 2/6] tools: ynl: convert enum selector to string for sub-message parsing Hangbin Liu
2026-10-01 1:51 ` sashiko-bot
2026-10-03 6:23 ` Hangbin Liu
2026-10-05 22:33 ` Jakub Kicinski
2026-09-30 1:50 ` [PATCH net-next v3 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 4/6] netlink: specs: rt-route: describe lwtunnel IP options Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 5/6] netlink: specs: rt-route: describe lwt BPF program options Hangbin Liu
2026-10-01 1:51 ` sashiko-bot
2026-10-03 6:09 ` Hangbin Liu
2026-09-30 1:50 ` [PATCH net-next v3 6/6] netlink: specs: rt-route: describe seg6-local attrs Hangbin Liu
2026-10-01 1:51 ` sashiko-bot
2026-10-03 6:17 ` Hangbin Liu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox