Re: [PATCH net-next 3/5] seg6: apply the PSP flavor together with NEXT-C-SID in SRv6 End

[Hangbin Liu <hangbin.liu@linux.dev>]

On Sun, Oct 11, 2026 at 09:23:08PM +0200, Andrea Mayer wrote:
> Since commit bdf3c0b9c10b ("seg6: add PSP flavor support for SRv6 End
> behavior"), an SRv6 End route can be set up with both the NEXT-C-SID and
> the PSP flavors, e.g.:
> 
>   ip -6 route add fcbb:0:100::/48 encap seg6local action End \
>           flavors next-csid,psp lblen 32 nflen 16 dev dum0
> 
> In RFC 9800, the NEXT-C-SID flavor (NEXT-CSID in the RFC) changes the
> End processing only when the Argument is not zero [1]. With a zero
> Argument (i.e. when the IPv6 DA carries no further C-SID), End is
> processed as in RFC 8986, and the PSP flavor (when set) applies
> unchanged [2]. If the packet arrives with Segments Left 1, PSP must
> then remove the SRH.
> 
> However, on a route with both the NEXT-C-SID and PSP flavors,
> input_action_end() always uses the NEXT-C-SID processing. The
> NEXT-C-SID processing handles a packet with a zero Argument as End
> without flavors, ignoring PSP. Therefore, if this packet arrives with
> Segments Left 1, the SRH is not removed.
> 
> Fix this by using the NEXT-C-SID processing only when the Argument is
> not zero or the route has no RFC 8986 flavor. Otherwise, the packet is
> processed as End with its RFC 8986 flavors, in end_flv8986_core(). With
> a zero Argument and Segments Left 1, PSP now removes the SRH before the
> packet is forwarded. If seg6_pop_srh() cannot remove the SRH, the packet
> is dropped, as on a route with the PSP flavor alone.
> 
> Found by manual code inspection and reproduced in a VM without kernel
> changes or error injection. A following commit adds tests for this case
> to srv6_end_flavors_test.sh. The tests reproduce the issue: they fail
> without this change and pass with it.
> 
> [1] - https://datatracker.ietf.org/doc/html/rfc9800#section-4.1.1
> [2] - https://datatracker.ietf.org/doc/html/rfc9800#section-4.1.7
> 
> Fixes: bdf3c0b9c10b ("seg6: add PSP flavor support for SRv6 End behavior")
> Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
> ---
>  net/ipv6/seg6_local.c | 50 ++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 47 insertions(+), 3 deletions(-)
> 
> diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> index 26cd4facbe36..427d12fedfc3 100644
> --- a/net/ipv6/seg6_local.c
> +++ b/net/ipv6/seg6_local.c
> @@ -551,6 +551,47 @@ static bool seg6_next_csid_enabled(__u32 fops)
>  	return fops & SEG6_F_LOCAL_FLV_NEXT_CSID;
>  }
>  
> +static bool seg6_flv8986_enabled(__u32 fops)
> +{
> +	return fops & SEG6_LOCAL_FLV8986_SUPP_OPS;
> +}
> +
> +/* check whether the NEXT-C-SID processing has to be used for the packet,
> + * instead of the RFC8986 flavors set for the given SRv6 End* behavior
> + * instance.
> + *
> + * This function returns:
> + *  - true, when the packet has to go through the NEXT-C-SID processing;
> + *  - false, when NEXT-C-SID is not configured or the packet has to be
> + *    processed on the basis of the RFC8986 flavors.
> + */
> +static bool seg6_use_next_csid(struct sk_buff *skb,
> +			       const struct seg6_flavors_info *finfo)
> +{
> +	const struct in6_addr *addr;
> +	__u32 fops = finfo->flv_ops;
> +
> +	if (!seg6_next_csid_enabled(fops))
> +		return false;
> +
> +	addr = &ipv6_hdr(skb)->daddr;
> +
> +	/* NEXT-C-SID and the RFC8986 flavors combine according to the
> +	 * DA.Argument (see RFC9800, sections 4.1.1 and 4.1.7):
> +	 *
> +	 *       DA.Argument   RFC8986 flavors   processing
> +	 *   (1) != 0          any               NEXT-C-SID only, SL unchanged
> +	 *   (2) == 0          none              the behavior, e.g. End
> +	 *   (3) == 0          one or more       the behavior with its flavors,
> +	 *                                       e.g. End with PSP
> +	 *
> +	 * In (2), the packet still goes through the NEXT-C-SID processing,
> +	 * which runs the behavior (e.g. End) when the DA.Argument is zero.
> +	 */
> +	return !seg6_flv8986_enabled(fops) ||
> +	       !seg6_next_csid_is_arg_zero(addr, finfo);

nit: based on the comment, maybe we can change the order to

	return !seg6_next_csid_is_arg_zero(addr, finfo) ||
	       !seg6_flv8986_enabled(fops);

No need to change if there is no new version patch.

> +}
> +
>  /* Processing of SRv6 End, End.X, and End.T behaviors can be extended through
>   * the flavors framework. These behaviors must report the subset of (flavor)
>   * operations they currently implement. In this way, if a user specifies a
> @@ -865,7 +906,10 @@ static int end_flv8986_core(struct sk_buff *skb, struct seg6_local_lwt *slwt)
>  	if (srh && !seg6_hmac_validate_skb(skb, srh))
>  		goto drop;
>  #endif
> -	flvmask = finfo->flv_ops;
> +	/* NEXT-C-SID, when configured, has already been evaluated by the
> +	 * caller. Only the RFC8986 flavors are left here.
> +	 */
> +	flvmask = finfo->flv_ops & ~SEG6_F_LOCAL_FLV_NEXT_CSID;
>  	if (unlikely(flvmask & ~SEG6_LOCAL_FLV8986_SUPP_OPS)) {
>  		pr_warn_once("seg6local: invalid RFC8986 flavors\n");
>  		goto drop;
> @@ -919,8 +963,8 @@ static int input_action_end(struct sk_buff *skb, struct seg6_local_lwt *slwt)
>  	if (!fops)
>  		return input_action_end_core(skb, slwt);
>  
> -	/* check for the presence of NEXT-C-SID since it applies first */
> -	if (seg6_next_csid_enabled(fops))
> +	/* NEXT-C-SID is evaluated first, when configured */
> +	if (seg6_use_next_csid(skb, finfo))
>  		return end_next_csid_core(skb, slwt);
>  
>  	/* the specific processing function to be performed on the packet
> -- 
> 2.43.0
> 

Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>

Thanks
Hangbin