On Tue, Feb 3, 2026, at 15:51, Gal Pressman wrote:

Hello Alice,

On 03/02/2026 14:20, Alice Mikityanska wrote:

quoted

quoted

quoted

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).

The behavior should be the same, the structure of the skbs the packet
originated from shouldn't affect this change.

quoted

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.

You will see a large packet with a single MSS value in tcpdump, and
that's consistent with the behavior we have for UDP tunnels.
tcpdump parses the packet without any issues.

Yeah, just checked tcpdump: it shows the full payload, regardless of UDP
length and IP length in the headers. Sounds good to me, thanks for the
clarifications!

quoted

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.

Feel free :).