From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jibin Zhang <jibin.zhang@mediatek.com>,
Eric Dumazet <edumazet@google.com>,
Neal Cardwell <ncardwell@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
"David S . Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Cc: wsd_upstream@mediatek.com, Jibin Zhang <jibin.zhang@mediatek.com>
Subject: Re: [PATCH v3] net: fix segmentation of forwarding fraglist GRO
Date: Sun, 25 Jan 2026 17:00:54 -0500 [thread overview]
Message-ID: <willemdebruijn.kernel.4c5ab6b532d7@gmail.com> (raw)
In-Reply-To: <20260124095021.3953-1-jibin.zhang@mediatek.com>
Jibin Zhang wrote:
> This patch enhances GSO segment checks by verifying the presence
> of frag_list and protocol consistency, addressing low throughput
> issues on IPv4 servers when used as hotspots
>
> Specifically, it fixes a bug in GSO segmentation when forwarding
> GRO packets with frag_list. The function skb_segment_list cannot
> correctly process GRO skbs converted by XLAT, because XLAT only
> converts the header of the head skb. As a result, skbs in the
> frag_list may remain unconverted, leading to protocol
> inconsistencies and reduced throughput.
>
> To resolve this, the patch uses skb_segment to handle forwarded
> packets converted by XLAT, ensuring that all fragments are
> properly converted and segmented.
>
> Signed-off-by: Jibin Zhang <jibin.zhang@mediatek.com>
> ---
> v3: Apply the same fix to tcp6_gso_segment(), as suggested.
>
> v2: To apply the added condition to a narrower scop
>
> In this version, the condition (skb_has_frag_list(gso_skb) &&
> (gso_skb->protocol == skb_shinfo(gso_skb)->frag_list->protocol))
> is moved into inner 'if' statement to a narrower scope.
>
> Send out the patch again for further discussion because:
>
> 1. This issue has a significant impact and has occurred in many
> countries and regions.
> 2. Currently, modifying BPF is not a good option, because BPF code
> cannot access the header of skb on the fraglist, and the required
> changes would affect a wide range of code.
> 3. Directly disabling GRO aggregation for XLAT flows is also not a
> good solution, as this change would disable GRO even when forwarding
> is not needed, and it would also require cooperation from all device
> drivers.
>
> [2]: https://patchwork.kernel.org/patch/14375646
>
> [1]: https://patchwork.kernel.org/patch/14350844
[PATCH net] and please include a Fixes tag and CC: stable.
>
> ---
> net/ipv4/tcp_offload.c | 4 +++-
> net/ipv4/udp_offload.c | 4 +++-
> net/ipv6/tcpv6_offload.c | 4 +++-
> 3 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
> index fdda18b1abda..6c2c10f37f87 100644
> --- a/net/ipv4/tcp_offload.c
> +++ b/net/ipv4/tcp_offload.c
> @@ -107,7 +107,9 @@ static struct sk_buff *tcp4_gso_segment(struct sk_buff *skb,
> if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST) {
> struct tcphdr *th = tcp_hdr(skb);
>
> - if (skb_pagelen(skb) - th->doff * 4 == skb_shinfo(skb)->gso_size)
> + if ((skb_pagelen(skb) - th->doff * 4 == skb_shinfo(skb)->gso_size) &&
> + skb_has_frag_list(skb) &&
Not all skbs with frag_list are SKB_GSO_FRAGLIST skbs.
Let's limit to those, which was the intent when skb_segment_list was
introduced.
Could XLAT set SKB_GSO_DODGY when modifying headers for GSO packets?
Not sure which exact code is being referred to. All such BPF helpers
in net/core/filter.c do. skb_segment has a further sanityf check for
odd frag_list geometry, but conditional on SKB_GSO_DODGY.
See also https://lore.kernel.org/netdev/willemdebruijn.kernel.30b0807bf46c0@gmail.com/
But in general: it is always safe to downgrade from skb_segment_list
to skb_segment. And fine to err on the side of caution esp. for any
packets that were modified along the way, so Ack on the general idea.
> + (skb->protocol == skb_shinfo(skb)->frag_list->protocol))
> return __tcp4_gso_segment_list(skb, features);
>
> skb->ip_summed = CHECKSUM_NONE;
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 19d0b5b09ffa..2a99f011793f 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -514,7 +514,9 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>
> if (skb_shinfo(gso_skb)->gso_type & SKB_GSO_FRAGLIST) {
> /* Detect modified geometry and pass those to skb_segment. */
> - if (skb_pagelen(gso_skb) - sizeof(*uh) == skb_shinfo(gso_skb)->gso_size)
> + if ((skb_pagelen(gso_skb) - sizeof(*uh) == skb_shinfo(gso_skb)->gso_size) &&
> + skb_has_frag_list(gso_skb) &&
> + (gso_skb->protocol == skb_shinfo(gso_skb)->frag_list->protocol))
> return __udp_gso_segment_list(gso_skb, features, is_ipv6);
>
> ret = __skb_linearize(gso_skb);
> diff --git a/net/ipv6/tcpv6_offload.c b/net/ipv6/tcpv6_offload.c
> index effeba58630b..3c7fd0362475 100644
> --- a/net/ipv6/tcpv6_offload.c
> +++ b/net/ipv6/tcpv6_offload.c
> @@ -170,7 +170,9 @@ static struct sk_buff *tcp6_gso_segment(struct sk_buff *skb,
> if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST) {
> struct tcphdr *th = tcp_hdr(skb);
>
> - if (skb_pagelen(skb) - th->doff * 4 == skb_shinfo(skb)->gso_size)
> + if ((skb_pagelen(skb) - th->doff * 4 == skb_shinfo(skb)->gso_size) &&
> + skb_has_frag_list(skb) &&
> + (skb->protocol == skb_shinfo(skb)->frag_list->protocol))
> return __tcp6_gso_segment_list(skb, features);
>
> skb->ip_summed = CHECKSUM_NONE;
> --
> 2.45.2
>
prev parent reply other threads:[~2026-01-25 22:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-24 9:50 [PATCH v3] net: fix segmentation of forwarding fraglist GRO Jibin Zhang
2026-01-25 22:00 ` Willem de Bruijn [this message]
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=willemdebruijn.kernel.4c5ab6b532d7@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jibin.zhang@mediatek.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=wsd_upstream@mediatek.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.