From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Shiming Cheng <shiming.cheng@mediatek.com>,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, matthias.bgg@gmail.com,
angelogioacchino.delregno@collabora.com, willemb@google.com,
daniel.zahka@gmail.com, alice@isovalent.com,
sd@queasysnail.net, eilaimemedsnaimel@gmail.com,
imv4bel@gmail.com, nbd@nbd.name, dsahern@kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Cc: stable@vger.kernel.org, steffen.klassert@secunet.com,
lena.wang@mediatek.com, shiming.cheng@mediatek.com
Subject: Re: [PATCH] net: gro: mark frag_list GRO packets as SKB_GSO_DODGY when a list element exceeds gso_size
Date: Tue, 29 Sep 2026 11:28:47 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.20906a8caa141@gmail.com> (raw)
In-Reply-To: <20260929100256.23192-1-shiming.cheng@mediatek.com>
Shiming Cheng wrote:
> When RX LRO (or similar offload) is enabled, the TCP/IPv4 GRO path may
> aggregate traffic using frag_list. The resulting skb is later segmented
> via the frag_list segmentation path (skb_segment_list()).
>
> However, some drivers can hand GRO/LRO-aggregated frames to the stack
> where individual frag_list elements are already larger than skb_shinfo(p)
> ->gso_size (i.e., an element itself contains multiple MSS worth of
> payload) and may be non-linear (nr_frags > 0). This shape is not
> naturally produced by the software GRO aggregation logic for devices
> without LRO, and can lead to unexpected behavior in the frag_list
> segmentation path.
Did you observe this with a specific driver?
We don't want to have to support every crazy driver scheme. The right
approach may be to fix the driver.
To understand the geometry: the driver passes a GSO skb with frag_list,
where frag_list members may be any size, not just gso_size? I.e., these
do not conform to SKB_GSO_FRAGLIST rules?
I don't recall immediately what the acceptable behavior for regular
GSO skbs with frag_list is. But for starters such a driver should not
advertiserr SKB_GSO_FRAGLIST.
>
> Detect this condition during frag_list aggregation and mark the
> aggregated packet as SKB_GSO_DODGY when a list element’s length exceeds
> gso_size. This forces a more conservative segmentation/linearization
> behavior downstream and avoids relying on assumptions that do not hold
> for LRO-produced aggregates.
>
> No change for normal software GRO aggregation: the new check only
> triggers when skb_shinfo(p)->gso_size is set and a frag_list element
> length exceeds that size.
>
> Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Shiming Cheng <shiming.cheng@mediatek.com>
> ---
> net/core/gro.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/core/gro.c b/net/core/gro.c
> index 29b4d02bf519..e70ecf19b0a7 100644
> --- a/net/core/gro.c
> +++ b/net/core/gro.c
> @@ -259,6 +259,9 @@ int skb_gro_receive_list(struct sk_buff *p, struct sk_buff *skb)
> skb_shinfo(p)->flags |= skb_shinfo(skb)->flags & SKBFL_SHARED_FRAG;
>
> NAPI_GRO_CB(skb)->same_flow = 1;
> + /* frag_list element larger than gso_size (already coalesced before list-append) */
> + if (skb_shinfo(p)->gso_size && skb->len > skb_shinfo(p)->gso_size)
> + skb_shinfo(p)->gso_type |= SKB_GSO_DODGY;
>
> return 0;
> }
> --
> 2.45.2
>
next prev parent reply other threads:[~2026-09-29 15:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 10:02 [PATCH] net: gro: mark frag_list GRO packets as SKB_GSO_DODGY when a list element exceeds gso_size Shiming Cheng
2026-09-29 10:08 ` netdev-bot+sinfo
2026-09-29 15:28 ` Willem de Bruijn [this message]
2026-10-03 10:25 ` netdev-bot+sashiko
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.20906a8caa141@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=alice@isovalent.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=daniel.zahka@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=eilaimemedsnaimel@gmail.com \
--cc=horms@kernel.org \
--cc=imv4bel@gmail.com \
--cc=kuba@kernel.org \
--cc=lena.wang@mediatek.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=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=shiming.cheng@mediatek.com \
--cc=stable@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=willemb@google.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.