On Wed, Sep 23, 2026 at 01:46:37PM +0200, Andrea Mayer wrote: > > @@ -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.
OK > > > + 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. I will add a comment for the function change. > > 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. Sure, I will do rebase once it merged to net-next. Thanks Hangbin
