* [PATCH net-next 1/6] net: lwtunnel: change encap fill order
2026-09-17 6:35 [PATCH net-next 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
@ 2026-09-17 6:35 ` Hangbin Liu
2026-09-21 6:38 ` netdev-bot+sashiko
2026-09-17 6:35 ` [PATCH net-next 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-17 6:35 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>
When decoding sub‑messages, YNL tries to fetch the "selector" (encap‑type)
first. However, lwtunnel fills encap‑payload data first, which causes YNL
to fail decoding the lwtunnel encap message.
Fixing this inside YNL would be complex, so change the order in the kernel
and emit encap_type first.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
net/core/lwtunnel.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/core/lwtunnel.c b/net/core/lwtunnel.c
index b01a395d9a96..f13dfa02e026 100644
--- a/net/core/lwtunnel.c
+++ b/net/core/lwtunnel.c
@@ -240,6 +240,10 @@ int lwtunnel_fill_encap(struct sk_buff *skb, struct lwtunnel_state *lwtstate,
lwtstate->type > LWTUNNEL_ENCAP_MAX)
return 0;
+ ret = nla_put_u16(skb, encap_type_attr, lwtstate->type);
+ if (ret)
+ return ret;
+
nest = nla_nest_start_noflag(skb, encap_attr);
if (!nest)
return -EMSGSIZE;
@@ -254,9 +258,6 @@ int lwtunnel_fill_encap(struct sk_buff *skb, struct lwtunnel_state *lwtstate,
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;
return 0;
--
2.55.0
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH net-next 1/6] net: lwtunnel: change encap fill order
2026-09-17 6:35 ` [PATCH net-next 1/6] net: lwtunnel: change encap fill order Hangbin Liu
@ 2026-09-21 6:38 ` netdev-bot+sashiko
0 siblings, 0 replies; 15+ messages in thread
From: netdev-bot+sashiko @ 2026-09-21 6:38 UTC (permalink / raw)
To: hangbin.liu
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms,
donald.hunter, netdev, linux-kernel, bpf, liuhangbin
Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.
Critical: 0 · High: 0 · Medium: 1 · Low: 1
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [Medium] Incomplete rollback in lwtunnel_fill_encap()
(net/core/lwtunnel.c:229-268): the reorder commits the selector…
- [Low] Concern (assessed INVALID by baseline verification, retained only
for policy combination): the commit message justifies the reorder by a…
--
net: lwtunnel: change encap fill order
This moves the encap-type attribute so it is written before the encap
nest in lwtunnel_fill_encap(), so that YNL can read the sub-message
selector before the payload it selects. No other behaviour was
intended to change.
> diff --git a/net/core/lwtunnel.c b/net/core/lwtunnel.c
> index b01a395d9a966..f13dfa02e026e 100644
> --- a/net/core/lwtunnel.c
> +++ b/net/core/lwtunnel.c
> @@ -240,6 +240,10 @@ int lwtunnel_fill_encap(struct sk_buff *skb, struct lwtunnel_state *lwtstate,
> lwtstate->type > LWTUNNEL_ENCAP_MAX)
> return 0;
>
> + ret = nla_put_u16(skb, encap_type_attr, lwtstate->type);
> + if (ret)
> + return ret;
> +
> nest = nla_nest_start_noflag(skb, encap_attr);
> if (!nest)
> return -EMSGSIZE;
[Severity: Medium]
Now that the type attribute is committed to the skb before the nest is
opened, can the -EOPNOTSUPP path leave it behind?
In lwtunnel_fill_encap() the failure label only rewinds the nest, and
-EOPNOTSUPP is translated into a successful return:
net/core/lwtunnel.c:lwtunnel_fill_encap() {
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 (ret)
goto nla_put_failure;
...
nla_put_failure:
nla_nest_cancel(skb, nest);
return (ret == -EOPNOTSUPP ? 0 : ret);
}
nla_nest_cancel() trims back only to the start of the nest, so the
encap_type_attr written just above it stays in the message. Before this
change the type attribute was emitted only after ops->fill_encap()
succeeded, so this path left the skb unchanged.
All callers treat the 0 return as success and finish the message, for
example fib_nexthop_info():
if (lwtunnel_fill_encap(skb, nhc->nhc_lwtstate,
RTA_ENCAP, RTA_ENCAP_TYPE) < 0)
goto nla_put_failure;
and the same "< 0" test appears in nh_fill_node(), rt_fill_info() and
rt6_fill_node(). Does that mean user space can now receive a route or
nexthop message carrying RTA_ENCAP_TYPE / NHA_ENCAP_TYPE with no encap
payload?
That shape is rejected by the kernel's own nexthop parser in
rtm_to_nh_config():
} else if (tb[NHA_ENCAP_TYPE]) {
NL_SET_ERR_MSG(extack, "LWT encapsulation attribute is missing");
goto out;
so tools that dump and replay nexthops would see -EINVAL on restore.
Would it work to record the write position before emitting the selector
and nlmsg_trim() back to it on the failure and -EOPNOTSUPP paths, or to
reserve the selector attribute and fill it in only once the payload fill
has succeeded?
The trigger requires lwtun_encaps[lwtstate->type] to be NULL or an ops
without a ->fill_encap handler while an lwtstate of that type is still
live, which the module reference taken in lwtunnel_build_state() makes
hard to reach in normal operation, but the code explicitly tests
ops->fill_encap so the branch does not look impossible.
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260917-ynl_rt_encap-v1-0-fbbe6e680571%40kylinos.cn
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH net-next 2/6] tools: ynl: convert enum selector to string for sub-message parsing
2026-09-17 6:35 [PATCH net-next 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
2026-09-17 6:35 ` [PATCH net-next 1/6] net: lwtunnel: change encap fill order Hangbin Liu
@ 2026-09-17 6:35 ` Hangbin Liu
2026-09-21 6:38 ` netdev-bot+sashiko
2026-09-17 6:35 ` [PATCH net-next 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-17 6:35 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.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
tools/net/ynl/pyynl/ynl_gen_c.py | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
index 2b3483db1b60..45bd7bc834b4 100755
--- a/tools/net/ynl/pyynl/ynl_gen_c.py
+++ b/tools/net/ynl/pyynl/ynl_gen_c.py
@@ -951,9 +951,17 @@ class TypeSubMessage(TypeNest):
sel_var = f"_sel_{sel}"
else:
sel_var = f"{var}->{sel}"
+
+ parse_sel = sel_var
+ if not self.selector.is_external() and self.selector.attr and \
+ "enum" in self.selector.attr.attr:
+ enum_name = self.selector.attr.attr["enum"]
+ str_fn = c_lower(self.family.ident_name + "-" + enum_name) + "_str"
+ parse_sel = f"{str_fn}({sel_var})"
+
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))",
+ 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};"]
--
2.55.0
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH net-next 2/6] tools: ynl: convert enum selector to string for sub-message parsing
2026-09-17 6:35 ` [PATCH net-next 2/6] tools: ynl: convert enum selector to string for sub-message parsing Hangbin Liu
@ 2026-09-21 6:38 ` netdev-bot+sashiko
0 siblings, 0 replies; 15+ messages in thread
From: netdev-bot+sashiko @ 2026-09-21 6:38 UTC (permalink / raw)
To: hangbin.liu
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms,
donald.hunter, netdev, linux-kernel, bpf, liuhangbin
Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.
Critical: 0 · High: 0 · Medium: 1 · Low: 2
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [Medium] TypeSubMessage._attr_get()
(tools/net/ynl/pyynl/ynl_gen_c.py:955-964) now emits…
- [Low] On the numeric/enum selector path newly enabled by this patch,
TypeSubMessage._attr_get() keeps the guard `if (!{sel_var})` / `return…
- [Low] Concern raised: the patch should carry a Fixes: tag pointing at
b9e03e263610 ("tools: ynl-gen: submsg: support parsing and rendering…
--
tools: ynl: convert enum selector to string for sub-message parsing
For non-external sub-message selectors that carry an enum, the generator now
wraps the selector value in the family's {enum}_str() helper before handing it
to the generated sub-message parser, so that the parser's strcmp() gets a
string instead of an integer.
A couple of questions about the generated code below.
> diff --git a/tools/net/ynl/pyynl/ynl_gen_c.py b/tools/net/ynl/pyynl/ynl_gen_c.py
> index 2b3483db1b60c..45bd7bc834b49 100755
> --- a/tools/net/ynl/pyynl/ynl_gen_c.py
> +++ b/tools/net/ynl/pyynl/ynl_gen_c.py
> @@ -951,9 +951,17 @@ class TypeSubMessage(TypeNest):
> sel_var = f"_sel_{sel}"
> else:
> sel_var = f"{var}->{sel}"
> +
> + parse_sel = sel_var
> + if not self.selector.is_external() and self.selector.attr and \
> + "enum" in self.selector.attr.attr:
> + enum_name = self.selector.attr.attr["enum"]
> + str_fn = c_lower(self.family.ident_name + "-" + enum_name) + "_str"
> + parse_sel = f"{str_fn}({sel_var})"
> +
> get_lines = [f'if (!{sel_var})',
> f'return ynl_submsg_failed(yarg, "{self.name}", "{selector}");',
[Severity: Low]
On this newly enabled path sel_var is a scalar struct member such as
dst->encap_type, not a string pointer, so the retained guard emits:
if (!dst->encap_type)
return ynl_submsg_failed(yarg, "encap", "encap-type");
For a string selector that test meant "attribute absent". For an integer
selector, is it able to distinguish an absent attribute (calloc'ed struct)
from an attribute that is present with enum value 0?
The presence bit is already recorded by the generated parser, since
Type.attr_get() emits:
dst->_present.<attr> = 1;
Would testing dst->_present.<sel> be more appropriate here?
I checked the in-tree specs and no sub-message format is currently keyed on
the enum entry whose value is 0 (rt-route encap-data formats start at mpls =
1, nftables obj-data formats start at counter = 1), so this looks latent
today. The Python decoder in tools/net/ynl/pyynl/lib/ynl.py
(_resolve_selector) performs no such zero-value rejection, so the two ynl
implementations would also disagree for such a spec.
> - f"if ({self.nested_render_name}_parse(&parg, {sel_var}, attr))",
> + f"if ({self.nested_render_name}_parse(&parg, {parse_sel}, attr))",
[Severity: Medium]
Can the return value of the {enum}_str() helper be NULL here? The helper
emitted by _put_enum_to_str_helper() is:
const char *rt_route_encap_type_str(enum rt_route_encap_type value)
{
if (value < 0 || value >= (int)YNL_ARRAY_SIZE(rt_route_encap_type_strmap))
return NULL;
return rt_route_encap_type_strmap[value];
}
so it returns NULL for any value outside the spec's enum range, and returns a
NULL table slot for a sparse enum with holes.
The generated sub-message parser from parse_rsp_submsg() dereferences the
selector as its very first action:
if (!strcmp(sel, "mpls"))
The only guard in front of it tests the integer sel_var, not the returned
pointer, so is there anything preventing strcmp(NULL, "mpls") here?
With the rt-route lwtunnel encap sub-message spec added later in this series
(encap-type u16 with enum encap-type, selecting encap-data), the generated
code becomes:
rt_route_encap_data_parse(&parg, rt_route_encap_type_str(dst->encap_type), attr)
The value comes from the kernel, and __ynl_attr_validate() in
tools/net/ynl/lib/ynl.c only checks the payload length for YNL_PT_U16, so an
RTA_ENCAP_TYPE value the generated code does not know about (for example a
new LWTUNNEL_ENCAP_* added by a kernel newer than the headers the code was
generated against, as happened for RPL, IOAM6 and XFRM) would reach the
helper unchecked. Would that crash the ynl-based user-space program?
For comparison, on the pre-existing string-selector path (rt-link and tc
kind), an unrecognized selector simply falls through every else if and the
generated parser returns 0. Does this change turn that benign no-match into
a NULL dereference?
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260917-ynl_rt_encap-v1-0-fbbe6e680571%40kylinos.cn
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH net-next 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support
2026-09-17 6:35 [PATCH net-next 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
2026-09-17 6:35 ` [PATCH net-next 1/6] net: lwtunnel: change encap fill order Hangbin Liu
2026-09-17 6:35 ` [PATCH net-next 2/6] tools: ynl: convert enum selector to string for sub-message parsing Hangbin Liu
@ 2026-09-17 6:35 ` Hangbin Liu
2026-09-21 6:38 ` netdev-bot+sashiko
2026-09-17 6:35 ` [PATCH net-next 4/6] netlink: specs: rt-route: describe lwtunnel IP options Hangbin Liu
` (2 subsequent siblings)
5 siblings, 1 reply; 15+ messages in thread
From: Hangbin Liu @ 2026-09-17 6:35 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, ila, seg6, rpl,
ioam6, xfrm) and IP/IP6 tunnel sets.
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 | 280 +++++++++++++++++++++++++++++-
tools/net/ynl/Makefile.deps | 9 +-
2 files changed, 287 insertions(+), 2 deletions(-)
diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index 253037ea5176..0e236da140dc 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,229 @@ 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
+ -
+ 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
+ -
+ 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
+ -
+ name: identifier
+ type: u64
+ -
+ name: locator-match
+ type: u64
+ -
+ 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
+ -
+ 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
+ -
+ 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
+ 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 2771375339d9..b35639cb26f5 100644
--- a/tools/net/ynl/Makefile.deps
+++ b/tools/net/ynl/Makefile.deps
@@ -44,7 +44,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_RTNETLINK_H,rtnetlink.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_SEG6_IPTUNNEL_H,seg6_iptunnel.h) \
+ $(call get_hdr_inc,_LINUX_RPL_IPTUNNEL_H,rpl_iptunnel.h) \
+ $(call get_hdr_inc,_LINUX_SEG6_LOCAL_H,seg6_local.h) \
+ $(call get_hdr_inc,_LWTUNNEL_H_,lwtunnel.h) \
+ $(call get_hdr_inc,_LINUX_ILA_H,ila.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 [flat|nested] 15+ messages in thread* Re: [PATCH net-next 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support
2026-09-17 6:35 ` [PATCH net-next 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support Hangbin Liu
@ 2026-09-21 6:38 ` netdev-bot+sashiko
0 siblings, 0 replies; 15+ messages in thread
From: netdev-bot+sashiko @ 2026-09-21 6:38 UTC (permalink / raw)
To: hangbin.liu
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms,
donald.hunter, netdev, linux-kernel, bpf, liuhangbin
Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.
Critical: 0 · High: 1 · Medium: 1 · Low: 1
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [High] Newly described lwtunnel encap attributes that the kernel
puts/gets in network byte order are declared as host-order integers,…
- [Medium] Generated C parser can dereference a NULL selector string:
with RTA_ENCAP modelled as a sub-message selected by the `encap-type`…
- [Low] The newly added selector enum (`encap-type`), the `encap-data`
sub-message and all eleven tunnel-specific attribute sets are added…
--
netlink: specs: rt-route: add lwtunnel encap sub-message support
This adds an encap-type enum to the rt-route spec and turns RTA_ENCAP into
a sub-message keyed by that enum, with new attribute sets describing the
mpls, ip, ila, ip6, seg6, bpf, seg6-local, rpl, ioam6 and xfrm payloads.
It also extends tools/net/ynl/Makefile.deps so the generated rt-route code
picks up the relevant uapi headers.
> 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
> @@ -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
[Severity: Low]
This isn't a bug, but the new encap-type definition, the encap-data
sub-message and all eleven new attribute sets (mpls-iptunnel, lwtunnel-ip,
ila-attrs, lwtunnel-ip6, seg6-iptunnel, lwt-bpf, seg6-local, rpl-iptunnel,
ioam6-iptunnel, lwt-xfrm) carry no doc properties, while the neighbouring
rt-route-notify and rt-route-flags definitions in the same file do document
their entries.
Could a doc be added for at least the selector enum and each attribute set,
including a note that some members are deliberately left as binary here and
converted in follow-up patches?
> +
> +sub-messages:
> + -
> + name: encap-data
> + formats:
> + -
> + value: mpls
> + attribute-set: mpls-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
[Severity: Medium]
Can this crash the generated C parser when the peer kernel knows an encap
type that the spec does not?
The enum here lists values 0..10 (none..xfrm, i.e. today's
LWTUNNEL_ENCAP_MAX). TypeSubMessage._attr_get() in
tools/net/ynl/pyynl/ynl_gen_c.py only guards the zero case:
if (!dst->encap_type)
return ynl_submsg_failed(yarg, "encap", "encap-type");
if (rt_route_encap_data_parse(&parg, rt_route_encap_type_str(dst->encap_type), attr))
and _put_enum_to_str_helper() generates the lookup as:
if (value < 0 || value >= (int)YNL_ARRAY_SIZE(rt_route_encap_type_strmap))
return NULL;
while the sub-message parser emitted by parse_rsp_submsg() starts with
if (!strcmp(sel, "mpls"))
with no NULL check on sel. So a binary built from this tree dumping routes
from a kernel that added LWTUNNEL_ENCAP_* value 11 would call
strcmp(NULL, "mpls") while parsing an ordinary RTM_GETROUTE reply.
Before this change RTA_ENCAP was type binary, so unknown encap types parsed
harmlessly. Should the enum-to-string conversion introduced by "tools: ynl:
convert enum selector to string for sub-message parsing" fall back to
ynl_submsg_failed() when the lookup returns NULL, given this spec is its
first consumer?
> -
> name: expires
> type: u32
> @@ -277,6 +332,229 @@ attribute-sets:
[ ... ]
> + -
> + name: lwtunnel-ip
> + name-prefix: lwtunnel-ip-
> + header: linux/lwtunnel.h
> + attributes:
> + -
> + name: id
> + type: u64
> + -
> + 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]
Do these declarations byte-swap the tunnel id and tunnel flags on
little-endian hosts?
dst and src above correctly carry byte-order: big-endian, but id and flags
do not, while the kernel encodes both in network order in
net/ipv4/ip_tunnel_core.c:
ip_tun_fill_encap_info()
nla_put_be64(skb, LWTUNNEL_IP_ID, tun_info->key.tun_id, LWTUNNEL_IP_PAD)
nla_put_be16(skb, LWTUNNEL_IP_FLAGS, ip_tunnel_flags_to_be16(...))
ip_tun_build_state()
tun_info->key.tun_id = nla_get_be64(tb[LWTUNNEL_IP_ID]);
Without a byte-order property, NlAttr.get_format() in
tools/net/ynl/pyynl/lib/ynl.py returns format_.native:
if byte_order:
return format_.big if byte_order == "big-endian" else format_.little
return format_.native
and the same format is used by _add_attr() when packing requests, so both
dumps and route creation would see reversed bytes, including flag bits such
as TUNNEL_KEY landing in the wrong byte.
The same question applies to the ila-attrs locator, identifier and
locator-match below, which are __be64 on the wire (note the __force casts in
net/ipv6/ila/ila_lwt.c):
p->locator.v64 = (__force __be64)nla_get_u64(tb[ILA_ATTR_LOCATOR]);
nla_put_u64_64bit(skb, ILA_ATTR_LOCATOR, (__force u64)p->locator.v64, ILA_ATTR_PAD)
and to lwtunnel-ip6 id and flags, which use nla_put_be64()/nla_put_be16()
for LWTUNNEL_IP6_ID and LWTUNNEL_IP6_FLAGS in ip6_tun_fill_encap_info().
> + -
> + 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
> + -
> + name: identifier
> + type: u64
> + -
> + name: locator-match
> + type: u64
[ ... ]
> + -
> + name: lwtunnel-ip6
> + name-prefix: lwtunnel-ip6-
> + header: linux/lwtunnel.h
> + attributes:
> + -
> + name: id
> + type: u64
[ ... ]
> + -
> + name: flags
> + type: u16
[ ... ]
> + -
> + name: seg6-local
> + name-prefix: seg6-local-
> + header: linux/seg6_local.h
> + attributes:
[ ... ]
> + -
> + name: nh4
> + type: u32
> + display-hint: ipv4
[Severity: High]
Should nh4 also carry byte-order: big-endian?
SEG6_LOCAL_NH4 is a raw struct in_addr in net/ipv6/seg6_local.c:
[SEG6_LOCAL_NH4] = NLA_POLICY_EXACT_LEN(sizeof(struct in_addr)),
...
memcpy(&slwt->nh4, nla_data(attrs[SEG6_LOCAL_NH4]), sizeof(struct in_addr));
With u32 plus display-hint: ipv4 and no byte-order, ynl unpacks and packs it
natively, so does an END.DX4 route created through ynl end up with a
byte-reversed next hop (192.0.2.1 written as 1.2.0.192), and dumps rendering
it reversed?
The affected attributes above (lwtunnel-ip id/flags, lwtunnel-ip6 id/flags,
ila-attrs locator/identifier/locator-match, seg6-local nh4) appear unchanged
through the end of the series, so respinning this patch rather than fixing it
later would keep the spec contract correct from the start.
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260917-ynl_rt_encap-v1-0-fbbe6e680571%40kylinos.cn
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH net-next 4/6] netlink: specs: rt-route: describe lwtunnel IP options
2026-09-17 6:35 [PATCH net-next 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
` (2 preceding siblings ...)
2026-09-17 6:35 ` [PATCH net-next 3/6] netlink: specs: rt-route: add lwtunnel encap sub-message support Hangbin Liu
@ 2026-09-17 6:35 ` Hangbin Liu
2026-09-21 6:38 ` netdev-bot+sashiko
2026-09-17 6:35 ` [PATCH net-next 5/6] netlink: specs: rt-route: describe lwt BPF program options Hangbin Liu
2026-09-17 6:35 ` [PATCH net-next 6/6] netlink: specs: rt-route: describe seg6-local actions, counters and flavors Hangbin Liu
5 siblings, 1 reply; 15+ messages in thread
From: Hangbin Liu @ 2026-09-17 6:35 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 | 59 +++++++++++++++++++++++++++++--
1 file changed, 57 insertions(+), 2 deletions(-)
diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index 0e236da140dc..6030d7cb8d0d 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -375,7 +375,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-
@@ -438,7 +439,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-
@@ -555,6 +557,59 @@ 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
+ -
+ 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
+ -
+ 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
+ -
+ name: dir
+ type: u8
+ -
+ name: hwid
+ type: u8
operations:
enum-model: directional
--
2.55.0
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH net-next 4/6] netlink: specs: rt-route: describe lwtunnel IP options
2026-09-17 6:35 ` [PATCH net-next 4/6] netlink: specs: rt-route: describe lwtunnel IP options Hangbin Liu
@ 2026-09-21 6:38 ` netdev-bot+sashiko
2026-09-21 9:26 ` Hangbin Liu
0 siblings, 1 reply; 15+ messages in thread
From: netdev-bot+sashiko @ 2026-09-21 6:38 UTC (permalink / raw)
To: hangbin.liu
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms,
donald.hunter, netdev, linux-kernel, bpf, liuhangbin
Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.
Critical: 0 · High: 0 · Medium: 2 (1) · Low: 1
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [Medium] New `lwtunnel-ip-opt-erspan.index` attribute in
Documentation/netlink/specs/rt-route.yaml is declared as host-order…
- [Medium] The new `lwtunnel-ip-opts` / `lwtunnel-ip-opt-geneve` sets
cannot represent multi-option Geneve tunnels.
- [Low] The four newly added attribute sets (`lwtunnel-ip-opts` at rt-
route.yaml:561, `lwtunnel-ip-opt-geneve` at 577, `lwtunnel-ip-opt-…
Pre-existing issues:
- [Medium] This problem wasn't introduced by this patch, but in the very
`lwtunnel-ip` / `lwtunnel-ip6` sets the patch edits, `id` is declared…
--
netlink: specs: rt-route: describe lwtunnel IP options
This converts the opaque binary opts attribute in the lwtunnel-ip and
lwtunnel-ip6 attribute sets into a nest pointing at a new lwtunnel-ip-opts
set, and adds three new sets describing the geneve, vxlan and erspan IP
tunnel options.
> diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> index 0e236da140dc5..6030d7cb8d0d1 100644
> --- a/Documentation/netlink/specs/rt-route.yaml
> +++ b/Documentation/netlink/specs/rt-route.yaml
> @@ -375,7 +375,8 @@ attribute-sets:
> type: pad
> -
> name: opts
> - type: binary # lwtunnel ip nest options
> + type: nest
> + nested-attributes: lwtunnel-ip-opts
[Severity: Medium]
This isn't a bug introduced by this patch, but while the lwtunnel-ip and
lwtunnel-ip6 sets are being touched here, both declare id as plain u64 and
flags as plain u16 with no byte-order property:
name: lwtunnel-ip
...
-
name: id
type: u64
...
-
name: flags
type: u16
The kernel encodes and decodes both as big-endian. In
ip_tun_fill_encap_info():
if (nla_put_be64(skb, LWTUNNEL_IP_ID, tun_info->key.tun_id,
LWTUNNEL_IP_PAD) ||
...
nla_put_be16(skb, LWTUNNEL_IP_FLAGS,
ip_tunnel_flags_to_be16(tun_info->key.tun_flags)) ||
and ip_tun_build_state() reads them back with nla_get_be64() /
nla_get_be16(). ip6_tun_fill_encap_info() and ip6_tun_build_state() do the
same for LWTUNNEL_IP6_ID and LWTUNNEL_IP6_FLAGS.
Would generated codecs therefore byte-swap the tunnel id and flags on
little-endian hosts? Since this patch adds byte-order: big-endian to a new
neighbouring attribute, would it make sense to annotate these two in the
same series so the edited sets are self-consistent?
[ ... ]
> @@ -555,6 +557,59 @@ 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
[Severity: Low]
Should these four new sets carry header: linux/lwtunnel.h?
The LWTUNNEL_IP_OPTS_*, LWTUNNEL_IP_OPT_GENEVE_*, LWTUNNEL_IP_OPT_VXLAN_*
and LWTUNNEL_IP_OPT_ERSPAN_* enums all live in
include/uapi/linux/lwtunnel.h, and every sibling lwtunnel set in this same
file already declares it (lwtunnel-ip, lwtunnel-ip6, lwt-bpf, lwt-xfrm).
In ynl_gen_c.py the header property is what suppresses re-rendering of the
enum:
for definition in parsed['definitions'] + parsed['attribute-sets']:
if 'header' not in definition:
continue
Without it, does C codegen re-define LWTUNNEL_IP_OPTS_GENEVE and friends
locally instead of including <linux/lwtunnel.h>, risking duplicate
definitions when both headers are used?
[Severity: Medium]
Can this set represent a tunnel carrying more than one Geneve option?
ip_tun_fill_encap_opts_geneve() opens a single LWTUNNEL_IP_OPTS_GENEVE nest
and then loops, emitting one CLASS/TYPE/DATA triplet per option inside that
one nest:
while (tun_info->options_len > offset) {
opt = ip_tunnel_info_opts(tun_info) + offset;
if (nla_put_be16(skb, LWTUNNEL_IP_OPT_GENEVE_CLASS,
opt->opt_class) || ...
On the input side ip_tun_parse_opts() accumulates repeated Geneve nests,
rejecting only cross-type repeats:
case LWTUNNEL_IP_OPTS_GENEVE:
if (type && type != IP_TUNNEL_GENEVE_OPT_BIT)
return -EINVAL;
Neither the outer geneve attribute nor the inner class/type/data attributes
are marked multi-attr: true. nlspec.py defaults to single:
self.is_multi = yaml.get('multi-attr', False)
and ynl.py then overwrites earlier values:
if not is_multi:
rsp[name] = decoded
So for a route created with something like
ip route add ... encap ip id 1 geneve_opts 0102:80:00001111,0102:81:00002222 ...
would a decoder keep only the last triplet, and would an encoder be unable
to express more than one option at all? The previous binary modelling of
opts preserved the whole payload, so is this conversion lossy as it stands?
Note that adding multi-attr only to the outer geneve attribute would not be
enough for reply decoding, since the repeated triplets live inside one nest.
> + -
> + 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
[Severity: Low]
Should data record the kernel's length constraints via checks: max-len?
geneve_opt_policy caps the attribute:
[LWTUNNEL_IP_OPT_GENEVE_DATA] = { .type = NLA_BINARY, .len = 127 },
and ip_tun_parse_opts_geneve() additionally requires 4-byte granularity:
data_len = nla_len(attr);
if (data_len % 4)
return -EINVAL;
so 124 bytes is the largest payload the kernel accepts. As written, can
spec-driven tooling build a request the kernel rejects with a bare -EINVAL?
> + -
> + 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
[Severity: Medium]
Is index missing byte-order: big-endian here?
The kernel treats LWTUNNEL_IP_OPT_ERSPAN_INDEX as big-endian on both
paths. ip_tun_fill_encap_opts_erspan() does:
nla_put_be32(skb, LWTUNNEL_IP_OPT_ERSPAN_INDEX, md->u.index))
and ip_tun_parse_opts_erspan() does:
md->u.index = nla_get_be32(attr);
nlspec.py reads byte_order = yaml.get('byte-order'), which is None when the
property is absent, so generated codecs would use native order. On
little-endian hosts, would an index of 1 decode as 0x01000000, and would a
request built from this spec program a swapped index that the kernel
accepts as-is?
The erspan_opt_policy entry is { .type = NLA_U32 }, which is a size-only
check and does not contradict the be32 accessors. The class attribute added
in lwtunnel-ip-opt-geneve in this same patch does carry
byte-order: big-endian, so this looks like an oversight rather than an
intentional difference.
> + -
> + name: dir
> + type: u8
> + -
> + name: hwid
> + type: u8
Thanks for looking at these.
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260917-ynl_rt_encap-v1-0-fbbe6e680571%40kylinos.cn
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH net-next 4/6] netlink: specs: rt-route: describe lwtunnel IP options
2026-09-21 6:38 ` netdev-bot+sashiko
@ 2026-09-21 9:26 ` Hangbin Liu
0 siblings, 0 replies; 15+ messages in thread
From: Hangbin Liu @ 2026-09-21 9:26 UTC (permalink / raw)
To: netdev-bot+sashiko
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms,
donald.hunter, netdev, linux-kernel, bpf, liuhangbin
On Mon, Sep 21, 2026 at 06:38:15AM +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential
> issue(s) to consider.
>
> Critical: 0 · High: 0 · Medium: 2 (1) · Low: 1
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [Medium] New `lwtunnel-ip-opt-erspan.index` attribute in
> Documentation/netlink/specs/rt-route.yaml is declared as host-order…
> - [Medium] The new `lwtunnel-ip-opts` / `lwtunnel-ip-opt-geneve` sets
> cannot represent multi-option Geneve tunnels.
Thanks, this is a new inspire. I will update it in my v3 patch and post 1
week later to make sure v2 have enough reviews.
Hangbin
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH net-next 5/6] netlink: specs: rt-route: describe lwt BPF program options
2026-09-17 6:35 [PATCH net-next 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
` (3 preceding siblings ...)
2026-09-17 6:35 ` [PATCH net-next 4/6] netlink: specs: rt-route: describe lwtunnel IP options Hangbin Liu
@ 2026-09-17 6:35 ` Hangbin Liu
2026-09-21 6:38 ` netdev-bot+sashiko
2026-09-17 6:35 ` [PATCH net-next 6/6] netlink: specs: rt-route: describe seg6-local actions, counters and flavors Hangbin Liu
5 siblings, 1 reply; 15+ messages in thread
From: Hangbin Liu @ 2026-09-17 6:35 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 | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index 6030d7cb8d0d..5e9537f7dfad 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -463,13 +463,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
@@ -503,7 +506,8 @@ attribute-sets:
type: u32
-
name: bpf
- type: binary
+ type: nest
+ nested-attributes: lwt-bpf-prog
-
name: vrftable
type: u32
@@ -610,6 +614,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 [flat|nested] 15+ messages in thread* Re: [PATCH net-next 5/6] netlink: specs: rt-route: describe lwt BPF program options
2026-09-17 6:35 ` [PATCH net-next 5/6] netlink: specs: rt-route: describe lwt BPF program options Hangbin Liu
@ 2026-09-21 6:38 ` netdev-bot+sashiko
2026-09-21 9:46 ` Hangbin Liu
0 siblings, 1 reply; 15+ messages in thread
From: netdev-bot+sashiko @ 2026-09-21 6:38 UTC (permalink / raw)
To: hangbin.liu
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms,
donald.hunter, netdev, linux-kernel, bpf, liuhangbin
Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.
Critical: 0 · High: 0 · Medium: 1 · Low: 1
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [Medium] Documentation/netlink/specs/rt-route.yaml re-points the
seg6-local `bpf` attribute (SEG6_LOCAL_BPF) at the newly added `lwt-…
- [Low] The new `lwt-bpf-prog` `name` attribute in
Documentation/netlink/specs/rt-route.yaml (lines 624-626) is declared…
--
netlink: specs: rt-route: describe lwt BPF program options
This changes the lwt-bpf in/out/xmit attributes and the seg6-local bpf
attribute in Documentation/netlink/specs/rt-route.yaml from binary to a
nest, and adds a new shared lwt-bpf-prog attribute set with fd and name
members.
> diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> index 6030d7cb8d0d1..5e9537f7dfad4 100644
> --- a/Documentation/netlink/specs/rt-route.yaml
> +++ b/Documentation/netlink/specs/rt-route.yaml
[ ... ]
> @@ -503,7 +506,8 @@ attribute-sets:
> type: u32
> -
> name: bpf
> - type: binary
> + type: nest
> + nested-attributes: lwt-bpf-prog
[Severity: Medium]
Should the seg6-local bpf attribute point at the lwt-bpf-prog set? This
attribute lives in the seg6-local set, which carries
header: linux/seg6_local.h, but lwt-bpf-prog below uses
name-prefix: lwt-bpf-prog-, so its members document and generate as
LWT_BPF_PROG_FD / LWT_BPF_PROG_NAME.
Those identifiers come from linux/lwtunnel.h:
enum {
LWT_BPF_PROG_UNSPEC,
LWT_BPF_PROG_FD,
LWT_BPF_PROG_NAME,
__LWT_BPF_PROG_MAX,
};
while the seg6-local nest is a separate uAPI namespace in
linux/seg6_local.h:
enum {
SEG6_LOCAL_BPF_PROG_UNSPEC,
SEG6_LOCAL_BPF_PROG,
SEG6_LOCAL_BPF_PROG_NAME,
__SEG6_LOCAL_BPF_PROG_MAX,
};
The values (1, 2) and payload types happen to coincide, so the wire format
still decodes, but does this end up documenting SRv6 attributes with
lwtunnel.h names? There also seems to be no header: value that can be
correct for a set shared between linux/lwtunnel.h and
linux/seg6_local.h.
Would a separate seg6-local-bpf-prog set with
header: linux/seg6_local.h be more accurate here?
Separately, the commit message says only:
Replace binary BPF attributes with a nested lwt-bpf-prog to support
lwt bpf prog options.
Could it also mention that the seg6-local bpf attribute is being re-typed,
since that is a different attribute space?
> @@ -610,6 +614,16 @@ attribute-sets:
> -
> name: hwid
> type: u8
> + -
> + name: lwt-bpf-prog
> + name-prefix: lwt-bpf-prog-
> + attributes:
> + -
> + name: fd
> + type: u32
[Severity: Medium]
Is fd the right name for attribute 1 in both directions? In requests
parse_nla_bpf() in net/ipv6/seg6_local.c does treat it as a descriptor:
fd = nla_get_u32(tb[SEG6_LOCAL_BPF_PROG]);
p = bpf_prog_get_type(fd, BPF_PROG_TYPE_LWT_SEG6LOCAL);
but on GET/dump put_nla_bpf() emits a program id, not a descriptor:
if (nla_put_u32(skb, SEG6_LOCAL_BPF_PROG, slwt->bpf.prog->aux->id))
return -EMSGSIZE;
So a spec-driven decoder would print slwt->bpf.prog->aux->id under a field
called fd, and feeding that value back into a request would resolve an
unrelated descriptor or fail. On the lwt-bpf side bpf_fill_lwt_prog() in
net/core/lwt_bpf.c never emits attribute 1 at all and only puts
LWT_BPF_PROG_NAME.
Would it be worth naming this member after the program reference/id, or at
least documenting the id-versus-fd asymmetry?
Note this appears unchanged at the end of the series (30e3ec46f708 still
has name: bpf with nested-attributes: lwt-bpf-prog and the fd member).
> + -
> + name: name
> + type: string
[Severity: Low]
Should this string carry a max-len? Both kernel consumers of this nest
bound it to MAX_PROG_NAME (256).
net/core/lwt_bpf.c:
static const struct nla_policy bpf_prog_policy[LWT_BPF_PROG_MAX + 1] = {
[LWT_BPF_PROG_FD] = { .type = NLA_U32, },
[LWT_BPF_PROG_NAME] = { .type = NLA_NUL_STRING,
.len = MAX_PROG_NAME },
};
net/ipv6/seg6_local.c:
static const struct nla_policy bpf_prog_policy[SEG6_LOCAL_BPF_PROG_MAX + 1] = {
[SEG6_LOCAL_BPF_PROG] = { .type = NLA_U32, },
[SEG6_LOCAL_BPF_PROG_NAME] = { .type = NLA_NUL_STRING,
.len = MAX_PROG_NAME },
};
As written the spec advertises an unbounded string, so tooling generated
from it will build a request that the kernel rejects with -EINVAL.
MAX_PROG_NAME is a private define in those two .c files, so the numeric
bound would need to be spelled out in the spec, and max-len does not count
the NUL terminator.
This is also still missing at the end of the series (30e3ec46f708).
>
> operations:
> enum-model: directional
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260917-ynl_rt_encap-v1-0-fbbe6e680571%40kylinos.cn
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH net-next 5/6] netlink: specs: rt-route: describe lwt BPF program options
2026-09-21 6:38 ` netdev-bot+sashiko
@ 2026-09-21 9:46 ` Hangbin Liu
0 siblings, 0 replies; 15+ messages in thread
From: Hangbin Liu @ 2026-09-21 9:46 UTC (permalink / raw)
To: netdev-bot+sashiko
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms,
donald.hunter, netdev, linux-kernel, bpf, liuhangbin
On Mon, Sep 21, 2026 at 06:38:17AM +0000, 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
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [Medium] Documentation/netlink/specs/rt-route.yaml re-points the
> seg6-local `bpf` attribute (SEG6_LOCAL_BPF) at the newly added `lwt-…
Thanks, I will update the SEG6_LOCAL_BPF attrs in the seg6 update (patch 06).
in v3.
Hangbin
> - [Low] The new `lwt-bpf-prog` `name` attribute in
> Documentation/netlink/specs/rt-route.yaml (lines 624-626) is declared…
>
> --
>
> netlink: specs: rt-route: describe lwt BPF program options
>
> This changes the lwt-bpf in/out/xmit attributes and the seg6-local bpf
> attribute in Documentation/netlink/specs/rt-route.yaml from binary to a
> nest, and adds a new shared lwt-bpf-prog attribute set with fd and name
> members.
>
> > diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> > index 6030d7cb8d0d1..5e9537f7dfad4 100644
> > --- a/Documentation/netlink/specs/rt-route.yaml
> > +++ b/Documentation/netlink/specs/rt-route.yaml
>
> [ ... ]
>
> > @@ -503,7 +506,8 @@ attribute-sets:
> > type: u32
> > -
> > name: bpf
> > - type: binary
> > + type: nest
> > + nested-attributes: lwt-bpf-prog
>
> [Severity: Medium]
> Should the seg6-local bpf attribute point at the lwt-bpf-prog set? This
> attribute lives in the seg6-local set, which carries
> header: linux/seg6_local.h, but lwt-bpf-prog below uses
> name-prefix: lwt-bpf-prog-, so its members document and generate as
> LWT_BPF_PROG_FD / LWT_BPF_PROG_NAME.
>
> Those identifiers come from linux/lwtunnel.h:
>
> enum {
> LWT_BPF_PROG_UNSPEC,
> LWT_BPF_PROG_FD,
> LWT_BPF_PROG_NAME,
> __LWT_BPF_PROG_MAX,
> };
>
> while the seg6-local nest is a separate uAPI namespace in
> linux/seg6_local.h:
>
> enum {
> SEG6_LOCAL_BPF_PROG_UNSPEC,
> SEG6_LOCAL_BPF_PROG,
> SEG6_LOCAL_BPF_PROG_NAME,
> __SEG6_LOCAL_BPF_PROG_MAX,
> };
>
> The values (1, 2) and payload types happen to coincide, so the wire format
> still decodes, but does this end up documenting SRv6 attributes with
> lwtunnel.h names? There also seems to be no header: value that can be
> correct for a set shared between linux/lwtunnel.h and
> linux/seg6_local.h.
>
> Would a separate seg6-local-bpf-prog set with
> header: linux/seg6_local.h be more accurate here?
>
> Separately, the commit message says only:
>
> Replace binary BPF attributes with a nested lwt-bpf-prog to support
> lwt bpf prog options.
>
> Could it also mention that the seg6-local bpf attribute is being re-typed,
> since that is a different attribute space?
>
> > @@ -610,6 +614,16 @@ attribute-sets:
> > -
> > name: hwid
> > type: u8
> > + -
> > + name: lwt-bpf-prog
> > + name-prefix: lwt-bpf-prog-
> > + attributes:
> > + -
> > + name: fd
> > + type: u32
>
> [Severity: Medium]
> Is fd the right name for attribute 1 in both directions? In requests
> parse_nla_bpf() in net/ipv6/seg6_local.c does treat it as a descriptor:
>
> fd = nla_get_u32(tb[SEG6_LOCAL_BPF_PROG]);
> p = bpf_prog_get_type(fd, BPF_PROG_TYPE_LWT_SEG6LOCAL);
>
> but on GET/dump put_nla_bpf() emits a program id, not a descriptor:
>
> if (nla_put_u32(skb, SEG6_LOCAL_BPF_PROG, slwt->bpf.prog->aux->id))
> return -EMSGSIZE;
>
> So a spec-driven decoder would print slwt->bpf.prog->aux->id under a field
> called fd, and feeding that value back into a request would resolve an
> unrelated descriptor or fail. On the lwt-bpf side bpf_fill_lwt_prog() in
> net/core/lwt_bpf.c never emits attribute 1 at all and only puts
> LWT_BPF_PROG_NAME.
>
> Would it be worth naming this member after the program reference/id, or at
> least documenting the id-versus-fd asymmetry?
>
> Note this appears unchanged at the end of the series (30e3ec46f708 still
> has name: bpf with nested-attributes: lwt-bpf-prog and the fd member).
>
> > + -
> > + name: name
> > + type: string
>
> [Severity: Low]
> Should this string carry a max-len? Both kernel consumers of this nest
> bound it to MAX_PROG_NAME (256).
>
> net/core/lwt_bpf.c:
>
> static const struct nla_policy bpf_prog_policy[LWT_BPF_PROG_MAX + 1] = {
> [LWT_BPF_PROG_FD] = { .type = NLA_U32, },
> [LWT_BPF_PROG_NAME] = { .type = NLA_NUL_STRING,
> .len = MAX_PROG_NAME },
> };
>
> net/ipv6/seg6_local.c:
>
> static const struct nla_policy bpf_prog_policy[SEG6_LOCAL_BPF_PROG_MAX + 1] = {
> [SEG6_LOCAL_BPF_PROG] = { .type = NLA_U32, },
> [SEG6_LOCAL_BPF_PROG_NAME] = { .type = NLA_NUL_STRING,
> .len = MAX_PROG_NAME },
> };
>
> As written the spec advertises an unbounded string, so tooling generated
> from it will build a request that the kernel rejects with -EINVAL.
> MAX_PROG_NAME is a private define in those two .c files, so the numeric
> bound would need to be spelled out in the spec, and max-len does not count
> the NUL terminator.
>
> This is also still missing at the end of the series (30e3ec46f708).
>
> >
> > operations:
> > enum-model: directional
>
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260917-ynl_rt_encap-v1-0-fbbe6e680571%40kylinos.cn
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH net-next 6/6] netlink: specs: rt-route: describe seg6-local actions, counters and flavors
2026-09-17 6:35 [PATCH net-next 0/6] netlink: add lwtunnel encap sub-message support to rt-route Hangbin Liu
` (4 preceding siblings ...)
2026-09-17 6:35 ` [PATCH net-next 5/6] netlink: specs: rt-route: describe lwt BPF program options Hangbin Liu
@ 2026-09-17 6:35 ` Hangbin Liu
2026-09-21 6:38 ` netdev-bot+sashiko
5 siblings, 1 reply; 15+ messages in thread
From: Hangbin Liu @ 2026-09-17 6:35 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 enum. Replace binary counters/flavors in seg6-local
with nested seg6-local-cnt and seg6-local-flv.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
---
Documentation/netlink/specs/rt-route.yaml | 59 +++++++++++++++++++++++++++++--
1 file changed, 57 insertions(+), 2 deletions(-)
diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
index 5e9537f7dfad..3929a877aa27 100644
--- a/Documentation/netlink/specs/rt-route.yaml
+++ b/Documentation/netlink/specs/rt-route.yaml
@@ -116,6 +116,29 @@ 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
sub-messages:
-
@@ -484,6 +507,7 @@ attribute-sets:
-
name: action
type: u32
+ enum: seg6-local-actions
-
name: srh
type: binary
@@ -513,10 +537,12 @@ attribute-sets:
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-
@@ -624,6 +650,35 @@ attribute-sets:
-
name: name
type: string
+ -
+ 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
+ -
+ name: lcblock-bits
+ type: u8
+ -
+ name: lcnode-fn-bits
+ type: u8
operations:
enum-model: directional
--
2.55.0
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH net-next 6/6] netlink: specs: rt-route: describe seg6-local actions, counters and flavors
2026-09-17 6:35 ` [PATCH net-next 6/6] netlink: specs: rt-route: describe seg6-local actions, counters and flavors Hangbin Liu
@ 2026-09-21 6:38 ` netdev-bot+sashiko
0 siblings, 0 replies; 15+ messages in thread
From: netdev-bot+sashiko @ 2026-09-21 6:38 UTC (permalink / raw)
To: hangbin.liu
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms,
donald.hunter, netdev, linux-kernel, bpf, liuhangbin
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.
Critical: 0 · High: 0 · Medium: 1 · Low: 0
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [Medium] Incomplete/misleading description of the SEG6_LOCAL_FLAVORS
operation field: the newly added `seg6-local-flv` attribute set…
--
netlink: specs: rt-route: describe seg6-local actions, counters and flavors
This adds a seg6-local-actions enum definition, annotates the seg6-local
action attribute with it, and replaces the binary counters/flavors
attributes with nests described by the new seg6-local-cnt and
seg6-local-flv attribute sets.
> diff --git a/Documentation/netlink/specs/rt-route.yaml b/Documentation/netlink/specs/rt-route.yaml
> index 5e9537f7dfad4..3929a877aa279 100644
> --- a/Documentation/netlink/specs/rt-route.yaml
> +++ b/Documentation/netlink/specs/rt-route.yaml
> @@ -116,6 +116,29 @@ definitions:
> - rpl
> - ioam6
> - xfrm
> + -
> + name: seg6-local-actions
> + type: enum
> + name-prefix: seg6-local-action-
> + enum-name:
> + entries:
> + - unspec
> + - end
> + - end-x
[ ... ]
> + - end-bpf
> + - end-dt46
>
> sub-messages:
> -
[ ... ]
> @@ -624,6 +650,35 @@ attribute-sets:
> -
> name: name
> type: string
[ ... ]
> + -
> + name: seg6-local-flv
> + name-prefix: seg6-local-flv-
> + attributes:
> + -
> + name: operation
> + type: u32
[Severity: Medium]
Should the operation attribute here also carry an enum annotation, with
enum-as-flags: true?
SEG6_LOCAL_FLV_OPERATION does not carry an ordinal, it carries a bitmask
built from the flavor-operation enum in include/uapi/linux/seg6_local.h:
enum {
SEG6_LOCAL_FLV_OP_UNSPEC,
SEG6_LOCAL_FLV_OP_PSP,
SEG6_LOCAL_FLV_OP_USP,
SEG6_LOCAL_FLV_OP_USD,
SEG6_LOCAL_FLV_OP_NEXT_CSID,
__SEG6_LOCAL_FLV_OP_MAX
};
net/ipv6/seg6_local.c turns those into bit positions:
#define SEG6_F_LOCAL_FLV_OP(flvname) BIT(SEG6_LOCAL_FLV_OP_##flvname)
and seg6_local_init() confirms the u32 attribute holds one bit per
operation:
BUILD_BUG_ON(SEG6_LOCAL_FLV_OP_MAX + 1 > BITS_PER_TYPE(__u32));
parse_nla_flavors() reads the attribute and validates it against the
per-action supported-ops mask, and put_nla_flavors() writes finfo->flv_ops
back, so both directions are masks.
As written, a user-space client generated from this spec sees an opaque
integer, and setting it to 4 for next-csid means BIT(2), i.e. USP, or
gets rejected with EINVAL depending on the action.
The sibling rt-* specs describe such fields with a flags definition plus
enum-as-flags, for example ifa-flags in
Documentation/netlink/specs/rt-addr.yaml and ifi-flags in
Documentation/netlink/specs/rt-link.yaml.
Since the same patch does add enum: seg6-local-actions for the action
attribute, the two enumerated fields of the same uAPI header end up
described inconsistently: action decodes symbolically while operation
stays a plain integer. Would it make sense to add the matching
type: flags definition (unspec/psp/usp/usd/next-csid) here as well, given
that the generated enum names are themselves user visible and changing
them later is awkward?
> + -
> + name: lcblock-bits
> + type: u8
> + -
> + name: lcnode-fn-bits
> + type: u8
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260917-ynl_rt_encap-v1-0-fbbe6e680571%40kylinos.cn
^ permalink raw reply [flat|nested] 15+ messages in thread