From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f53.google.com (mail-yx1-f53.google.com [74.125.224.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0166C30CDA9 for ; Sun, 25 Jan 2026 22:00:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769378457; cv=none; b=H4GtBgJyIfKfyOncIB6Y4lDtz8tpt/haTuP8KKM1+V+re9HSMDvsbliIW2QEFk1rG0fqSiyrBqcWbKkD2D/mGJ2+Ea2WQzS3ksAegC7qzCEDqgy4o5MjoNLjglrt09M/aAyyDQzTOeP9nUF//LLOLRVxun1G5N6z3F4qnh8ZDsM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769378457; c=relaxed/simple; bh=jclKtdJuZtCUFK1atwM6/A5wtddZpbuJR/UgpxglLqw=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=fx4FDLV/o7t8VTQwaII0wThce5IokCyJw2FWVX4N8GtICHwpiMmOYIkyFy9Tru+A4rSFaNNB/d4wrtEFEcYX/IeJYKEgl+yJgy6vD713NFZh2F1ZYw0bpGKWdq5d/o8UtumDrLSjL+Q2Ox6atczQ0bZg5LE0Gp9V6T+xdAbL4ac= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Eb3DYGFf; arc=none smtp.client-ip=74.125.224.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Eb3DYGFf" Received: by mail-yx1-f53.google.com with SMTP id 956f58d0204a3-649523de905so5043908d50.1 for ; Sun, 25 Jan 2026 14:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769378455; x=1769983255; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=fAA6S4oPNmkGryTm0KBSPRHi5Lj0tu35Mdjk5cYMuDc=; b=Eb3DYGFf57Cv+8SS+sYq/BlxzSU+wRENnadkVD/D3lRG8w6bItXGM7t+GihAiHIwkq iQR0IB+bGxkPIpHctaFSy4oOYZ3fHYAcqgDhpFtzunSQI+nTUQdw8rK5e3BdCiwPo2OR FVpW2WRFHb6P/RpSsflSa+3NkvqJ2gdpDVg1cZ7s7GVGyWvrn2rl7ihyFj1mZKCrFTPJ a0B6AywfrnopRaeekKpmD9JWqNU0Bp+RoSPduJsfPkb/AXEz4BDvs4U3vcTs2PVzli7E Hp+IBRh3JAOLoaMBH9wXPtSoMlOSWHV23Pqg1T2aCrFM1zBBzRuA1ragSBIb1rGl8CRc +TvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769378455; x=1769983255; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fAA6S4oPNmkGryTm0KBSPRHi5Lj0tu35Mdjk5cYMuDc=; b=mKSTLqa+IrqOEpaRTQ/lmKM5DYioQphCs39B+7wfjTo3fB8WayeCaTMPVlgpt8MZLJ 4kwG2EGCuIwLycwyaHJ2xysChnqOnoVZuhqwhVPP3JrQ3q7+cv6VTG6540LLNH6wWlaI 2wa/uV3XLt4yh01qJlcQQu4BBljAtaf2zXejYicAtSTD5gTlrSntpN3VqQ5LPzhUaUeJ lgN5hwsBI9d8nNa9IZErhxZGk4a5rRhVH/ofKG/5vLRLxI8QXG3+cWn2SiNdVWcZSMET kcawiFs2MTAlmaj4vn0HbDzNVVnKKWSt4grnFE6p5NJxupqJ4QMIZuJS6+2h4Ph0nFN2 HP5A== X-Forwarded-Encrypted: i=1; AJvYcCUM8KWTSCVO0w7knNDHtzAz3lSYL0kZGKw/D4DpkbyA6jqQwIiDw4bnYSxw6UzkV94VJ3pCF/hfcIsTIvs=@vger.kernel.org X-Gm-Message-State: AOJu0YzuOxR2He8anrY/xZvO3ZHvmprn0s11h2rDU1FrKHUdVhYZap5y QxsT53ChFsHbflN8am1Z9OX9kS2eHifZ+WTFCwj9wWV2o0tqeL88FtuC X-Gm-Gg: AZuq6aLXolve6rtES7JId0GZ4JB5JQ/aVD2H+0QEI1Xeb3eFd9hZhIga3fy9Pz7il/1 d21T+rfPdOiTFSk1gvNwy/xl8TI3nxRQmYLaWhXdnTTUKkWzb83WFyVG6XCLQ8iOdSdaX3YJ58n TZrx3Z/8kwX2AVzQ/+1hq2R346ZYglJ/tDaiLFhbK8KwEyy1VSzwEv5KptBEzxWMwRvvM+FZPpM /kXYgwe3jsrEHNac40fUpBXso/jKK4pH4Nep4u1NDQWBW2hL2cXdrGlA5JvtXs8ZgtLzbE9PTfA eTsJ+Wq2nLdzN2wkHXPEVCZ6ARb4VkVZc+W41CUQEaQw1ZfUeg9xpnwkLKn5uu8rUTgVS014p6L jJbFoInBiifc/wYGFmi1/N1Nhc4eQRt8IUb5ZzKtdPGhQzZHTM+bSdg6sPK6kIqLWNpzyBMmGGh 8DLIGwthHPJwiHsQPut61DKjs6XgKuvIC/Y06rAaq/I/PpK4ERgBeMi8yvFkE= X-Received: by 2002:a05:690e:12ce:b0:649:47f1:26e0 with SMTP id 956f58d0204a3-6497140db99mr1986222d50.38.1769378454977; Sun, 25 Jan 2026 14:00:54 -0800 (PST) Received: from gmail.com (21.33.48.34.bc.googleusercontent.com. [34.48.33.21]) by smtp.gmail.com with UTF8SMTPSA id 00721157ae682-7943ae2d7f9sm40457437b3.0.2026.01.25.14.00.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Jan 2026 14:00:54 -0800 (PST) Date: Sun, 25 Jan 2026 17:00:54 -0500 From: Willem de Bruijn To: Jibin Zhang , Eric Dumazet , Neal Cardwell , Kuniyuki Iwashima , "David S . Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Simon Horman , Matthias Brugger , AngeloGioacchino Del Regno , 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 Message-ID: In-Reply-To: <20260124095021.3953-1-jibin.zhang@mediatek.com> References: <20260124095021.3953-1-jibin.zhang@mediatek.com> Subject: Re: [PATCH v3] net: fix segmentation of forwarding fraglist GRO Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 > --- > 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 >