netdev - Re: [PATCH net-next 1/3] udp: gso: Use single MSS length in UDP header for GSO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <fb617b34-7760-4e3f-903f-c7380d28ed40@app.fastmail.com>
Date: Tue, 03 Feb 2026 14:20:16 +0200
From: "Alice Mikityanska" <alice@...tmail.im>
To: "Gal Pressman" <gal@...dia.com>,
 "Willem de Bruijn" <willemdebruijn.kernel@...il.com>
Cc: "Igor Russkikh" <irusskikh@...vell.com>,
 "Boris Pismenny" <borisp@...dia.com>, "Saeed Mahameed" <saeedm@...dia.com>,
 "Leon Romanovsky" <leon@...nel.org>, "Tariq Toukan" <tariqt@...dia.com>,
 "Mark Bloch" <mbloch@...dia.com>, "David Ahern" <dsahern@...nel.org>,
 "Simon Horman" <horms@...nel.org>, "Alexander Duyck" <alexanderduyck@...com>,
 linux-rdma@...r.kernel.org, "Dragos Tatulea" <dtatulea@...dia.com>,
 "David S. Miller" <davem@...emloft.net>,
 "Eric Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>,
 "Paolo Abeni" <pabeni@...hat.com>, "Andrew Lunn" <andrew+netdev@...n.ch>,
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/3] udp: gso: Use single MSS length in UDP header for
 GSO_PARTIAL

On Mon, Jan 26, 2026, at 19:53, Willem de Bruijn wrote:
> Gal Pressman wrote:
>> In GSO_PARTIAL segmentation, set the UDP length field to the single
>> segment size (gso_size + UDP header) instead of the large MSS size.
>> This provides hardware with a template length value for final
>> segmentation, similar to how tunnel GSO_PARTIAL handles outer headers
>> in UDP tunnels.
>> 
>> This will remove the need to manually adjust the UDP header length in
>> the drivers, as can be seen in subsequent patches.
>> 
>> This was suggested by Alex in 2018:
>> https://lore.kernel.org/netdev/CAKgT0UcdnUWgr3KQ=RnLKigokkiUuYefmL-ePpDvJOBNpKScFA@mail.gmail.com/
>> 
>> Reviewed-by: Dragos Tatulea <dtatulea@...dia.com>
>> Signed-off-by: Gal Pressman <gal@...dia.com>
>
> Reviewed-by: Willem de Bruijn <willemb@...gle.com>
>
> This only affects the udp header value when using GSO_PARTIAL, and
> these are the only two drivers that adversize USO using GSO_PARTIAL.

I stumbled upon this patch when I was rebasing my stuff and saw a
(trivial) conflict. I've got a couple of questions on this change, and
I'd be glad if you could clarify it for me.

>> ---
>>  net/ipv4/udp_offload.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
>> index 19d0b5b09ffa..89e0b48b60ae 100644
>> --- a/net/ipv4/udp_offload.c
>> +++ b/net/ipv4/udp_offload.c
>> @@ -483,11 +483,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>  	struct sock *sk = gso_skb->sk;
>>  	unsigned int sum_truesize = 0;
>>  	struct sk_buff *segs, *seg;
>> +	__be16 newlen, msslen;
>>  	struct udphdr *uh;
>>  	unsigned int mss;
>>  	bool copy_dtor;
>>  	__sum16 check;
>> -	__be16 newlen;
>>  	int ret = 0;
>>  
>>  	mss = skb_shinfo(gso_skb)->gso_size;
>> @@ -555,6 +555,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>  		return segs;
>>  	}
>>  
>> +	msslen = htons(sizeof(*uh) + mss);
>> +
>>  	/* GSO partial and frag_list segmentation only requires splitting
>>  	 * the frame into an MSS multiple and possibly a remainder, both
>>  	 * cases return a GSO skb. So update the mss now.

What about the frag_list case? The comment says it would be a GSO SKB
too (as I understand frag_list, it would be a linked list of SKBs
forming one single packet). Is it appropriate to set UDP len = MSS in
this case too? I'm not sure which code reads UDP len afterwards, I
couldn't find any, so maybe its value doesn't matter at all (except for
hardware, which this patch aims for).

Is it possible that this GSO_PARTIAL or frag_list packet shows up in
tcpdump with UDP len set like this? E.g., if the GSO_PARTIAL
segmentation happens before entering a veth pipe, and tcpdump listens on
the other end? If so, tcpdump could fail to parse such a packet.

I haven't tried to reproduce any of these yet; I decided to ask first
because you have more context. I'll appreciate if you can give me a clue
whether my concerns are valid or not.

Other than that, I think the patch could be made simpler, if you just
drop mss *= gso_segs below, and stick to newlen, which would be equal to
msslen (now unneeded), and newlen and mss are not used anywhere else.
I'll include this simplification in my next series, if you don't mind.

>> @@ -584,7 +586,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>>  		if (!seg->next)
>>  			break;
>>  
>> -		uh->len = newlen;
>> +		uh->len = msslen;
>>  		uh->check = check;
>>  
>>  		if (seg->ip_summed == CHECKSUM_PARTIAL)
>> -- 
>> 2.40.1
>>