[{"id":3677742,"web_url":"http://patchwork.ozlabs.org/comment/3677742/","msgid":"<72814fe9-7abc-111e-6142-d2f3455aa220@ssi.bg>","list_archive_url":null,"date":"2026-04-15T15:35:03","subject":"Re: [PATCH net v4] ipvs: fix MTU check for GSO packets in tunnel\n mode","submitter":{"id":2825,"url":"http://patchwork.ozlabs.org/api/people/2825/","name":"Julian Anastasov","email":"ja@ssi.bg"},"content":"Hello,\n\nOn Wed, 15 Apr 2026, Yingnan Zhang wrote:\n\n> Currently, IPVS skips MTU checks for GSO packets by excluding them with\n> the !skb_is_gso(skb) condition. This creates problems when IPVS tunnel\n> mode encapsulates GSO packets with IPIP headers.\n> \n> The issue manifests in two ways:\n> \n> 1. MTU violation after encapsulation:\n> When a GSO packet passes through IPVS tunnel mode, the original MTU\n> check is bypassed. After adding the IPIP tunnel header, the packet\n> size may exceed the outgoing interface MTU, leading to unexpected\n> fragmentation at the IP layer.\n> \n> 2. Fragmentation with problematic IP IDs:\n> When net.ipv4.vs.pmtu_disc=1 and a GSO packet with multiple segments\n> is fragmented after encapsulation, each segment gets a sequentially\n> incremented IP ID (0, 1, 2, ...). This happens because:\n> \n> a) The GSO packet bypasses MTU check and gets encapsulated\n> b) At __ip_finish_output, the oversized GSO packet is split into\n> separate SKBs (one per segment), with IP IDs incrementing\n> c) Each SKB is then fragmented again based on the actual MTU\n> \n> This sequential IP ID allocation differs from the expected behavior\n> and can cause issues with fragment reassembly and packet tracking.\n> \n> Fix this by properly validating GSO packets using\n> skb_gso_validate_network_len(). This function correctly validates\n> whether the GSO segments will fit within the MTU after segmentation. If\n> validation fails, send an ICMP Fragmentation Needed message to enable\n> proper PMTU discovery.\n> \n> Fixes: 4cdd34084d53 (\"netfilter: nf_conntrack_ipv6: improve fragmentation handling\")\n> Signed-off-by: Yingnan Zhang <342144303@qq.com>\n\n\tLooks good to me for the nf tree, thanks!\n\nAcked-by: Julian Anastasov \n\n> ---\n> v4:\n> - Introduce a new helper function ip_vs_exceeds_mtu() to improve readability (reviewer feedback)\n> \n> v3: https://lore.kernel.org/netdev/tencent_73010FBD5FA1C05C3BC23A07A50B11CEC90A@qq.com/\n> v2: https://lore.kernel.org/netdev/tencent_CA2C1C219C99D315086BE55E8654AF7E6009@qq.com/\n> v1: https://lore.kernel.org/netdev/tencent_4A3E1C339C75D359093BE4F08648AFAA6009@qq.com/\n> ---\n> ---\n> net/netfilter/ipvs/ip_vs_xmit.c | 16 ++++++++++++++--\n> 1 file changed, 14 insertions(+), 2 deletions(-)\n> \n> diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c\n> index 0fb5162992e5..64dfdf8b00c4 100644\n> --- a/net/netfilter/ipvs/ip_vs_xmit.c\n> +++ b/net/netfilter/ipvs/ip_vs_xmit.c\n> @@ -102,6 +102,18 @@ __ip_vs_dst_check(struct ip_vs_dest *dest)\n> \treturn dest_dst;\n> }\n> \n> +/* Based on ip_exceeds_mtu(). */\n> +static bool ip_vs_exceeds_mtu(const struct sk_buff *skb, unsigned int mtu)\n> +{\n> +\tif (skb->len <= mtu)\n> +\t\treturn false;\n> +\n> +\tif (skb_is_gso(skb) && skb_gso_validate_network_len(skb, mtu))\n> +\t\treturn false;\n> +\n> +\treturn true;\n> +}\n> +\n> static inline bool\n> __mtu_check_toobig_v6(const struct sk_buff *skb, u32 mtu)\n> {\n> @@ -112,7 +124,7 @@ __mtu_check_toobig_v6(const struct sk_buff *skb, u32 mtu)\n> \t\tif (IP6CB(skb)->frag_max_size > mtu)\n> \t\t\treturn true; /* largest fragment violate MTU */\n> \t}\n> -\telse if (skb->len > mtu && !skb_is_gso(skb)) {\n> +\telse if (ip_vs_exceeds_mtu(skb, mtu)) {\n> \t\treturn true; /* Packet size violate MTU size */\n> \t}\n> \treturn false;\n> @@ -232,7 +244,7 @@ static inline bool ensure_mtu_is_adequate(struct netns_ipvs *ipvs, int skb_af,\n> \t\t\treturn true;\n> \n> \t\tif (unlikely(ip_hdr(skb)->frag_off & htons(IP_DF) &&\n> -\t\t\t skb->len > mtu && !skb_is_gso(skb) &&\n> +\t\t\t ip_vs_exceeds_mtu(skb, mtu) &&\n> \t\t\t !ip_vs_iph_icmp(ipvsh))) {\n> \t\t\ticmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,\n> \t\t\t\t htonl(mtu));\n> -- \n> 2.51.0.windows.1\n\nRegards\n\n--\nJulian Anastasov ","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","netfilter-devel@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (4096-bit key;\n unprotected) header.d=ssi.bg header.i=@ssi.bg header.a=rsa-sha256\n header.s=ssi header.b=UVO4X2mZ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11927-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (4096-bit key) header.d=ssi.bg header.i=@ssi.bg header.b=\"UVO4X2mZ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=193.238.174.39","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=ssi.bg","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=ssi.bg"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwllC5s6fz1yCv\n\tfor ; Thu, 16 Apr 2026 01:42:31 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 5CF63302A0AE\n\tfor ; Wed, 15 Apr 2026 15:35:52 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 08341221FB1;\n\tWed, 15 Apr 2026 15:35:45 +0000 (UTC)","from mx.ssi.bg (mx.ssi.bg [193.238.174.39])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id D406E3DFC78;\n\tWed, 15 Apr 2026 15:35:31 +0000 (UTC)","from mx.ssi.bg (localhost [127.0.0.1])\n\tby mx.ssi.bg (Potsfix) with ESMTP id 236FC21107;\n\tWed, 15 Apr 2026 18:35:19 +0300 (EEST)","from box.ssi.bg (box.ssi.bg [193.238.174.46])\n\tby mx.ssi.bg (Potsfix) with ESMTPS;\n\tWed, 15 Apr 2026 18:35:17 +0300 (EEST)","from ja.ssi.bg (unknown [213.16.62.126])\n\tby box.ssi.bg (Potsfix) with ESMTPSA id 450DF608CD;\n\tWed, 15 Apr 2026 18:35:15 +0300 (EEST)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby ja.ssi.bg (8.18.1/8.18.1) with ESMTP id 63FFZ3hV058241;\n\tWed, 15 Apr 2026 18:35:04 +0300"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776267340; cv=none;\n b=eA4Qv39ZiEKNYtHB9akUbcz/Iwn/zzY8NxWRoCP8GfsoJwgiHQF1EXe9S+kkEo57YRlzBDXnzqypeKkI1AnRnW6Rq561RXJ4EBxnURw1BD0Gv8B0SNjd338gbkpP1oJkiYb6YN50uaMp0AyUCdP3/Mj7q/CF+raGgdkdWo3zj8s=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776267340; c=relaxed/simple;\n\tbh=PSHo872UTpSY7Pd7+/Sgn/7YWlvCJs+jK6EXZQzMhfY=;\n\th=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=p+8nI0uuHGY0afAprBdykRZJdpGf6FN9T9I5oZWm8wdyOq4MUXQMcqhNTQjpCiL16HxeHiNlnDhP8ov7pCoarUR6HIDpYrTMQjTx3PeFIY/IBWtEa8NyDzhWYyRRDe1tnqrBCEz3PIthEqRvlf4TD14eN15TY+LZDI/HiW1EGQo=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=ssi.bg;\n spf=pass smtp.mailfrom=ssi.bg;\n dkim=pass (4096-bit key) header.d=ssi.bg header.i=@ssi.bg header.b=UVO4X2mZ;\n arc=none smtp.client-ip=193.238.174.39","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ssi.bg; h=cc:cc\n\t:content-type:content-type:date:from:from:in-reply-to:message-id\n\t:mime-version:references:reply-to:subject:subject:to:to; s=ssi;\n\t bh=OUQKghrpmJGe/+qFiqhRsCk1OBnY75g47ZnibPNkAnc=; b=UVO4X2mZF2We\n\tYVrfnNa0vWaQN0olivm7j5OAMUwiElxHCRXUs94wj/4nEx8wilxOmesQp8Bt7xy5\n\tlwXre+RBqyqO8oS1NJ+VSQwsT6YVHT5AW/mFKB0gjXjEkYByMhUabrdVbAo4+aHJ\n\tAQauZbAAdazl0pLxlZg7fVDEbVrWPvuI7sEUF561IVThPDhqb4B/VgjO22eJ737A\n\tPWQ5XCfeVzcAvLNl3NMwX5BjO8eeVr9vD/hV5YL8Ai3Z/ZZOx+FoIOTxydpdoOL+\n\tt28e2pWuBHw38a7NzSVIBKL6EQ9q0uk+9LSXR1/2Hv6SeucZivtIDhU0tgcOikFT\n\tBcugsptzPtDh2XGFByYPN5yrOHJzn3W0M7hrmwZ9MqIJJYgqufD40+Ic6724CIYg\n\tsj6inbLzVWyMbPbLWrnzGJHZSDQyHJtS8E3Y935SlerFqYYu+SeRX4TI9GwL7VU3\n\tmCsr2qt3dIkVlc/zWj5dLdH3FXl0vEhObLI0qQLvHIgVYomIR/PxbBOItn5plr+q\n\tsh2RsTHxzb227gSg/94ioFntkUpeRtrIfjMaR31bDSdmf2G8uHYdL3D2U+9r2Pi7\n\tdE+3lAqfuW1qIZUeE+/4CFUZZ2GRqf2TQ/zeDTO9Tp0cOB1U1xAuyRInFJkgD5rB\n\t6QgjYmtva8tB115e2VMj/4X43HCf+Xw=","Date":"Wed, 15 Apr 2026 18:35:03 +0300 (EEST)","From":"Julian Anastasov ","To":"Yingnan Zhang <342144303@qq.com>","cc":"pablo@netfilter.org, coreteam@netfilter.org, davem@davemloft.net,\n edumazet@google.com, fw@strlen.de, horms@verge.net.au,\n kuba@kernel.org,\n linux-kernel@vger.kernel.org, lvs-devel@vger.kernel.org,\n netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,\n pabeni@redhat.com, phil@nwl.cc","Subject":"Re: [PATCH net v4] ipvs: fix MTU check for GSO packets in tunnel\n mode","In-Reply-To":"","Message-ID":"<72814fe9-7abc-111e-6142-d2f3455aa220@ssi.bg>","References":"","Precedence":"bulk","X-Mailing-List":"netfilter-devel@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII"}}]