Netdev List
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: hangbin.liu@linux.dev
Cc: andrea.mayer@uniroma2.it, davem@davemloft.net, kuba@kernel.org,
	pabeni@redhat.com, horms@kernel.org, shuah@kernel.org,
	edumazet@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	liuhangbin@kylinos.cn
Subject: Re: [PATCH net-next v2 2/5] seg6: add RFC8986 flavor support for End.X
Date: Sat, 10 Oct 2026 10:21:02 +0000	[thread overview]
Message-ID: <179162766256.434549.13511080924871737471@kernel.org> (raw)
In-Reply-To: <20261009-srv6_flavors_endx-v2-2-56ac7f838f41@kylinos.cn>

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] End.X now accepts the flavor pair NEXT-C-SID + PSP but only
  applies NEXT-C-SID.

--

seg6: add RFC8986 flavor support for End.X

This patch adds PSP flavor processing to the SRv6 End.X behavior by reusing
end_flv8986_core(). It also widens SEG6_LOCAL_END_X_FLV_SUPP_OPS so that
End.X advertises PSP support alongside NEXT-C-SID.

> diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> index 4fcfcd48cfaed..521a9b0c09290 100644
> --- a/net/ipv6/seg6_local.c
> +++ b/net/ipv6/seg6_local.c
> @@ -121,7 +121,8 @@ struct bpf_lwt_prog {
>  
>  #define SEG6_LOCAL_END_FLV_SUPP_OPS	(SEG6_F_LOCAL_FLV_NEXT_CSID | \
>  					 SEG6_LOCAL_FLV8986_SUPP_OPS)
> -#define SEG6_LOCAL_END_X_FLV_SUPP_OPS	SEG6_F_LOCAL_FLV_NEXT_CSID
> +#define SEG6_LOCAL_END_X_FLV_SUPP_OPS	(SEG6_F_LOCAL_FLV_NEXT_CSID | \
> +					 SEG6_LOCAL_FLV8986_SUPP_OPS)
>  
>  struct seg6_flavors_info {
>  	/* Flavor operations */

[ ... ]

> @@ -923,12 +924,20 @@ static int input_action_end_x(struct sk_buff *skb, struct seg6_local_lwt *slwt)
>  {
>  	const struct seg6_flavors_info *finfo = &slwt->flv_info;
>  	__u32 fops = finfo->flv_ops;
> +	int ret;
> +
> +	if (!fops)
> +		return input_action_end_x_core(skb, slwt);
>  
>  	/* check for the presence of NEXT-C-SID since it applies first */
>  	if (seg6_next_csid_enabled(fops))
>  		return end_x_next_csid_core(skb, slwt);

[Severity: Medium]
Now that SEG6_LOCAL_END_X_FLV_SUPP_OPS is wider, what happens when an
End.X instance is configured with both next-csid and psp?

parse_nla_flavors() only rejects bits that fall outside the supported mask:

net/ipv6/seg6_local.c:parse_nla_flavors() {
    ...
	if (rc < 0 || (fops & ~supp_fops)) {
		NL_SET_ERR_MSG(extack, "Unsupported Flavor operation(s)");
		return -EOPNOTSUPP;
	}
    ...
}

So NEXT_CSID|PSP is now accepted for SEG6_LOCAL_ACTION_END_X. It gets
stored in flv_ops and reported back to userspace as configured.

On the data path, input_action_end_x() returns through the NEXT-C-SID
branch above and never reaches end_flv8986_core(). Once the C-SID argument
is used up, end_x_next_csid_core() falls back to plain End.X processing:

net/ipv6/seg6_local.c:end_x_next_csid_core() {
    ...
	if (seg6_next_csid_is_arg_zero(daddr, finfo))
		return input_action_end_x_core(skb, slwt);
    ...
}

input_action_end_x_core() only calls advance_nextseg() and then
input_action_end_x_finish(). It never calls seg6_pop_srh(), even when
SL == 1.

Does that mean the configured psp flavor is silently ignored, and packets
leave with the SRH still attached? A downstream node with seg6_enabled=0
would then drop them, and nothing reports an error at configuration time.

This also seems to contradict the comment above
seg6_flv_supp_ops_by_action():

 * ... if a user specifies a
 * flavor combination that is not supported by a given End* behavior, the
 * kernel refuses to instantiate the tunnel reporting the error.

Before this patch, End.X refused psp entirely. End already has the same
mismatch in input_action_end(); this patch carries it over to End.X.

The note below the --- line says this combination is not handled and that
Andrea is preparing a fix. That note won't be in the commit log, though.
Nothing in the code or the commit message rejects or documents the
combination, and net/ipv6/seg6_local.c is not changed again after this
patch.

Could parse_nla_flavors() reject NEXT_CSID combined with any RFC8986
flavor? Or could the End.X mask stay at SEG6_F_LOCAL_FLV_NEXT_CSID until
combined processing is in place?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261009-srv6_flavors_endx-v2-0-56ac7f838f41%40kylinos.cn

  reply	other threads:[~2026-10-10 10:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09  9:58 [PATCH net-next v2 0/5] seg6: add End.X PSP flavor support and selftests Hangbin Liu
2026-10-09  9:58 ` [PATCH net-next v2 1/5] seg6: split final End process out of flavor processing Hangbin Liu
2026-10-09  9:58 ` [PATCH net-next v2 2/5] seg6: add RFC8986 flavor support for End.X Hangbin Liu
2026-10-10 10:21   ` netdev-bot+sashiko [this message]
2026-10-12  0:32     ` Hangbin Liu
2026-10-12  0:59   ` Andrea Mayer
2026-10-12  1:38     ` Hangbin Liu
2026-10-09  9:58 ` [PATCH net-next v2 3/5] selftests: seg6: move SRv6 End PSP setup into its own helper Hangbin Liu
2026-10-10 10:21   ` netdev-bot+sashiko
2026-10-12  0:33     ` Hangbin Liu
2026-10-09  9:58 ` [PATCH net-next v2 4/5] selftest: seg6: add explicit cleanup for SRv6 End PSP test Hangbin Liu
2026-10-09  9:58 ` [PATCH net-next v2 5/5] selftests: seg6: add End.X PSP selftest Hangbin Liu
2026-10-10 10:21   ` netdev-bot+sashiko
2026-10-12  0:47     ` Hangbin Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=179162766256.434549.13511080924871737471@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrea.mayer@uniroma2.it \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=hangbin.liu@linux.dev \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=liuhangbin@kylinos.cn \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox