From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-b2-smtp.messagingengine.com (fhigh-b2-smtp.messagingengine.com [202.12.124.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8A0541427A for ; Wed, 13 May 2026 11:49:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.153 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778672946; cv=none; b=JbUBQyXAnDdBHQckyFwaxXIFSecBDh3tkDyBcxDX/8X9Ulmb/5Mb5dqh0ee4jVvdK5rPye4SUshd8EsF7dQYh837zkGvma9xAAWbpBApeYUuSwDzVecHRHjw5tH2aoIaFbtmy73eo0ErVa0c3/i6ZhBzc0Q4CAq4brXOtY1HmYU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778672946; c=relaxed/simple; bh=1QIxWlWTB4NtBgfgBm7FF5qlNTVYp0iacKSMhJfEj18=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=Kite6doO8V3TTYUs/ZEyWU1XbVcgm41VARhnSAc4f1kJZjN8NoQKAOWbk+rWu9smVrGsF9OD8QKTLg7fF1T6nBzDvit5appda2L0qS2WlF0x0D5kM08btluwTITJWBFjtXsVBPpjbbJv2XexwWYcegxq4ZdJPO4ijukiDhmlhXc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fastmail.im; spf=pass smtp.mailfrom=fastmail.im; dkim=pass (2048-bit key) header.d=fastmail.im header.i=@fastmail.im header.b=koSUU7EJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=SndV3drr; arc=none smtp.client-ip=202.12.124.153 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fastmail.im Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fastmail.im Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fastmail.im header.i=@fastmail.im header.b="koSUU7EJ"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="SndV3drr" Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.stl.internal (Postfix) with ESMTP id 5E3227A0156; Wed, 13 May 2026 07:49:02 -0400 (EDT) Received: from phl-imap-14 ([10.202.2.87]) by phl-compute-10.internal (MEProxy); Wed, 13 May 2026 07:49:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.im; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1778672942; x=1778759342; bh=vtU642UQcTS1yFh2yFytTiYauavllYh3YMTs+oQbXg0=; b= koSUU7EJ1Kk/MYoGNnMok0yWADgFqOpAYwdPKL1Di1IP0tM3vjd0WqBcwQuEjL94 QeV1mKJGH+pPCAFa8B5ZTuQ3fxaeqUaZlrSGYvjBl+kzWRxYy38KqdYwVU1rAY3O WG+Jg9XqoxvYvcagl0etYovL7o5ay2kDhSJKzBAZvPaV3GE/PSfm/iWGfOUDfbmv j5mgdsklrummcWsTRMd8IXfDIW0qp989xqlwZYEvezXJH9zWmdYGAT1SYb/uD1a6 Fun+sSwb/00ne+PruQmFj8eZwKB8LCD/Zaq+8hwXuAmmRXpxgr7xYzMu19mX0lCs Aq2nRISK9RI/zOJmsQscEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1778672942; x= 1778759342; bh=vtU642UQcTS1yFh2yFytTiYauavllYh3YMTs+oQbXg0=; b=S ndV3drrJod0pbAaUQsGolSQYbtGI5B16aSGqIjyY2vKfhqZI/yFMbMaJ7+UBn61P TSqRQPDVk0ngLnO4GaaqfPmPI9Azpr8Hgh3dIfIsCEjS5phuWo7SNPamIQqOMzzt unXNuPlIYWSoWKb9WCHodnB0LDsNVlEHlkNVIxuInIc5N0ghDpWdVMmYu1Tdvssb iW+nC5sE3BgbamZY+CHl6MOw5fWBJOupk2+WUeVOsx2pG7K942SSeFayXJtSTAzA pSrg/TOEA1qppjb4yDkc3IKtnJmOG0zh9j76g+lVBY+yReGmMSrVcYBZeZRgtG8K E4LHGjSiX9Ex7Y4KCq5pg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdduvdegheekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedftehlihgt vgcuofhikhhithihrghnshhkrgdfuceorghlihgtvgdrkhgvrhhnvghlsehfrghsthhmrg hilhdrihhmqeenucggtffrrghtthgvrhhnpefhgfevgeeljeegleeiffduheegieehtdff tdetvdffieelkedthfejleejgfeftdenucffohhmrghinhepkhgvrhhnvghlrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlihgt vgdrkhgvrhhnvghlsehfrghsthhmrghilhdrihhmpdhnsggprhgtphhtthhopeduuddpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepuggrvhgvmhesuggrvhgvmhhlohhfthdr nhgvthdprhgtphhtthhopegvughumhgriigvthesghhoohhglhgvrdgtohhmpdhrtghpth htohepfihilhhlvghmsgesghhoohhglhgvrdgtohhmpdhrtghpthhtohephhhorhhmshes khgvrhhnvghlrdhorhhgpdhrtghpthhtohepkhhusggrsehkvghrnhgvlhdrohhrghdprh gtphhtthhopehmrghtthhhvgifrdhstghhfigrrhhtiieslhhinhhugidruggvvhdprhgt phhtthhopegrnhgurhgvfidonhgvthguvghvsehluhhnnhdrtghhpdhrtghpthhtohepug htrghtuhhlvggrsehnvhhiughirgdrtghomhdprhgtphhtthhopehgrghlsehnvhhiughi rgdrtghomh X-ME-Proxy: Feedback-ID: i559e4809:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 5FCFDC4006E; Wed, 13 May 2026 07:49:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Wed, 13 May 2026 13:48:41 +0200 From: "Alice Mikityanska" To: "Gal Pressman" , "David S. Miller" , "Eric Dumazet" , "Jakub Kicinski" , "Paolo Abeni" , "Andrew Lunn" , netdev@vger.kernel.org Cc: "Simon Horman" , "Dragos Tatulea" , "Willem de Bruijn" , "Matthew Schwartz" Message-Id: <23e6e0f4-29ee-4f86-b02d-8c8d881c51f7@app.fastmail.com> In-Reply-To: References: <20260513074349.2152146-1-gal@nvidia.com> Subject: Re: [PATCH net] udp: Fix UDP length on last GSO_PARTIAL segment Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, May 13, 2026, at 13:28, Gal Pressman wrote: > On 13/05/2026 13:08, Alice Mikityanska wrote: >> On Wed, May 13, 2026, at 11:43, Gal Pressman wrote: >>> On 13/05/2026 12:17, Alice Mikityanska wrote: >>>> On Wed, May 13, 2026, at 09:43, Gal Pressman wrote: >>>>> Following the cited commit, __udp_gso_segment() writes single MSS length >>>>> in the UDP header. >>>>> The cited patch doesn't account for the fact that the last segment could >>>>> be a GSO skb by itself. This could happen when the size of the packet is >>>>> a multiple of MSS, hence the first segment is also the last one (there >>>>> is no need for a remainder skb). >>>>> >>>>> When the post-loop segment is a GSO skb, assign the single MSS length in >>>>> the UDP header. >>>>> >>>>> Fixes: b10b446ce7ad ("udp: gso: Use single MSS length in UDP header for >>>>> GSO_PARTIAL") >>>>> Reported-by: Matthew Schwartz >>>>> Closes: >>>>> https://lore.kernel.org/all/6c3fb15e-711d-4b8d-b152-e03d9b05293f@linux.dev/ >>>>> Tested-by: Matthew Schwartz >>>>> Reviewed-by: Dragos Tatulea >>>>> Signed-off-by: Gal Pressman >>>>> --- >>>>> net/ipv4/udp_offload.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c >>>>> index a0813d425b71..71df45f9488a 100644 >>>>> --- a/net/ipv4/udp_offload.c >>>>> +++ b/net/ipv4/udp_offload.c >>>>> @@ -604,7 +604,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb, >>>>> seg->data_len); >>>>> check = csum16_add(csum16_sub(uh->check, uh->len), newlen); >>>>> >>>>> - uh->len = newlen; >>>>> + uh->len = skb_is_gso(seg) ? msslen : newlen; >>>>> uh->check = check; >>>> >>>> This is going to have the same checksum bug as your first commit, which >>>> I'm fixing in [1]. You should use the right value of either msslen or >>>> newlen when modifying check a couple of lines above. >>> >>> I tend to agree that the checksum seems to have the wrong value, the >>> reason I chose not to change it is because my work only moved the UDP >>> length assignment from the drivers to the stack. >>> >>> The "wrong" checksum value was used regardless of my change, >> >> The wrong checksum was visible only inside the driver, and since the >> hardware didn't care (due to the offload), it worked well. It was the >> driver business to make sure the corresponding hardware likes the >> packet. After commit b10b446ce7ad ("udp: gso: Use single MSS length in >> UDP header for GSO_PARTIAL"), however, the wrong checksum moved one >> abstraction layer higher - to the networking stack, which attempts to >> keep the checksum correct for a more generic case. It's not the same, >> and while I'm trying to fix one occurrence, I'd prefer not to >> introduce more. >> >>> and I >>> prefer not to change it as part of this work. >>> >>>> >>>> That said, maybe you can base your patch on top of my checksum fix? For >>>> the last packet, it will then be: >>>> >>>> if (!skb_is_gso(seg)) >>>> newlen = /* the new value */; >>>> /* keep newlen as is otherwise: my newlen is your msslen */ >>>> check = csum16_add(csum16_sub(uh->check, uh->len), newlen); >>>> uh->len = newlen; >>>> uh->check = check; >>>> >>>> [1]: https://lore.kernel.org/netdev/20260512165648.386518-3-alice.kernel@fastmail.im/ >>> >>> As I mentioned in the other thread, this fix goes to net, I can't take >>> your patch. >> >> Ah, that's right. Still, I guess you can take mine to net for the >> checksum fix. > > Do you think it is suitable for net? This is always a mystery to me... I've had different experiences: sometimes I am asked to resubmit less important fixes to -next, sometimes a fix is a fix and must go to net. This one is a refactoring useful for my further patches + the checksum fix, which we get for free and which I considered not important enough to submit to net (hardware offload fixes the checksum in most cases anyway). Following the "a fix is a fix" logic, we may try sending it to net. What do you think? > Would you like to rephrase the > commit message accordingly? > > If you can send me an updated version I will take it and submit both (or > you can submit mine if you prefer).