From: Andrea Mayer <andrea.mayer@uniroma2.it>
To: Hangbin Liu <hangbin.liu@linux.dev>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, Shuah Khan <shuah@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Hangbin Liu <liuhangbin@kylinos.cn>,
stefano.salsano@uniroma2.it,
Andrea Mayer <andrea.mayer@uniroma2.it>
Subject: Re: [PATCH net-next 1/5] seg6: split final End process out of flavor processing
Date: Wed, 23 Sep 2026 13:46:37 +0200 [thread overview]
Message-ID: <20260923134637.4e56d6c422e3f89dd17f4a63@uniroma2.it> (raw)
In-Reply-To: <20260922-srv6_flavors_endx-v1-1-4d01c05c47b7@kylinos.cn>
On Tue, 22 Sep 2026 16:54:43 +0800
Hangbin Liu <hangbin.liu@linux.dev> wrote:
Hi Hangbin,
thanks for the patch.
> From: Hangbin Liu <liuhangbin@kylinos.cn>
>
> 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@kylinos.cn>
> ---
> 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
next prev parent reply other threads:[~2026-09-23 11:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 8:54 [PATCH net-next 0/5] seg6: add End.X PSP flavor support and selftests Hangbin Liu
2026-09-22 8:54 ` [PATCH net-next 1/5] seg6: split final End process out of flavor processing Hangbin Liu
2026-09-23 11:46 ` Andrea Mayer [this message]
2026-09-24 8:11 ` Hangbin Liu
2026-09-22 8:54 ` [PATCH net-next 2/5] seg6: add RFC8986 flavor support for End.X Hangbin Liu
2026-09-23 16:05 ` Andrea Mayer
2026-09-24 10:55 ` Hangbin Liu
2026-09-24 11:57 ` netdev-bot+sashiko
2026-09-22 8:54 ` [PATCH net-next 3/5] selftests: seg6: move SRv6 End PSP setup into its own helper Hangbin Liu
2026-09-24 11:57 ` netdev-bot+sashiko
2026-09-22 8:54 ` [PATCH net-next 4/5] selftest: seg6: add explicit cleanup for SRv6 End PSP test Hangbin Liu
2026-09-24 11:57 ` netdev-bot+sashiko
2026-09-22 8:54 ` [PATCH net-next 5/5] selftests: seg6: add End.X PSP selftest Hangbin Liu
2026-09-23 1:48 ` 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=20260923134637.4e56d6c422e3f89dd17f4a63@uniroma2.it \
--to=andrea.mayer@uniroma2.it \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--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 \
--cc=stefano.salsano@uniroma2.it \
/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
all inboxes | Powered by JetHome®