On Tue, 22 Sep 2026 16:54:43 +0800 Hangbin Liu <[email protected]> wrote:
Hi Hangbin, thanks for the patch. > From: Hangbin Liu <[email protected]> > > 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 <[email protected]> > --- > 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
