Re: [PATCH net-next 1/5] seg6: split final End process out of flavor processing

[Andrea Mayer]

On Tue, 22 Sep 2026 16:54:43 +0800
Hangbin Liu <hangbin.liu@xxxxxxxxx> wrote:

Hi Hangbin,
thanks for the patch.

> From: Hangbin Liu <liuhangbin@xxxxxxxxxx>
> 
> Move the final End forwarding step out of end_flv8986_core() and return
> success to the caller instead.
> 
> Currently end_flv8986_core() performs both RFC8986 flavor processing and
> final End forwarding by calling input_action_end_finish(). That couples
> flavor handling with the End-specific forwarding path, which makes it
> hard to reuse the same flavor logic for other End variants.
> 
> Split the two steps so input_action_end() does:
>   1) end_flv8986_core() for flavor processing
>   2) input_action_end_finish() for final forwarding
> 
> This keeps end_flv8986_core() focused on RFC8986/PSP flavor semantics
> and makes it easier to plug the same flavor core into End.X/T later.
> 
> Signed-off-by: Hangbin Liu <liuhangbin@xxxxxxxxxx>
> ---
>  net/ipv6/seg6_local.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> index d1070aec7b72..584e6aca3893 100644
> --- a/net/ipv6/seg6_local.c
> +++ b/net/ipv6/seg6_local.c
> @@ -804,7 +804,7 @@ static int end_flv8986_core(struct sk_buff *skb, struct seg6_local_lwt *slwt)
>  		goto drop;
>  	}
>  
> -	return input_action_end_finish(skb, slwt);
> +	return 0;
>  
>  drop:
>  	kfree_skb(skb);
> @@ -816,6 +816,7 @@ static int input_action_end(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_core(skb, slwt);
> @@ -829,7 +830,10 @@ static int input_action_end(struct sk_buff *skb, struct seg6_local_lwt *slwt)
>  	 * information extracted from the packet, e.g. presence/absence of SRH,
>  	 * Segment Left = 0, etc.
>  	 */
> -	return end_flv8986_core(skb, slwt);
> +	ret = end_flv8986_core(skb, slwt);
> +	if (ret)
> +		return ret;

A nit: a blank line before the final return would match the rest of
the file.

> +	return input_action_end_finish(skb, slwt);
>  }

This changes the semantics of end_flv8986_core(): it no longer
forwards the packet, it only processes it, and the caller does the
finish step. Is it worth saying so in a comment above the function? A
future caller that misses it would leak the skb.

A heads-up: reviewing this made me notice that a fix I have pending
for net touches these same lines. It makes the skb data writable
before advance_nextseg() modifies Segments Left and the IPv6
destination address, since today a clone sees the change.
It also turns the "kfree_skb(skb); return -EINVAL;" right below into
kfree_skb_reason(). Since it goes through net, this hunk may need a
rebase once net is merged back into net-next.

Ciao,
Andrea