diff options
| author | Jiayuan Chen <jiayuan.chen@linux.dev> | 2026-08-15 15:03:36 +0800 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-08-20 12:14:23 -0700 |
| commit | 2640e64195948a601430d230c9864f5426574cde (patch) | |
| tree | 400dcd29eee484864bc61d9cf8aebbfcb4e91a37 /tools/perf/scripts/python/task-analyzer.py | |
| parent | ec518a7c4ba13ea0b94a50cc79584e6d578e4791 (diff) | |
net: advertise TCP MSS from the configured MTU, not the learned PMTU
The MSS a host puts in its SYN tells the peer how big a segment it may
send us. Right now we can shrink it with a PMTU we learned on our own
send path, which is the wrong direction entirely.
On asymmetric paths this bites - think DSR load balancers, where the
request side goes through a smaller-MTU overlay. We learn a small PMTU
going out, then advertise a small MSS, and the peer stays capped for the
whole connection even though its path back to us is wide. MSS only shows
up in the SYN and never grows back.
On symmetric paths we lose nothing by dropping it either: the peer runs
its own PMTU discovery and usually already knows the real path MTU.
So work out the advertised MSS from the configured route or device MTU
and ignore the learned PMTU. Our send side is unchanged, still clamped by
tcp_current_mss(). Add ip_dst_mtu_configured()/ip6_dst_mtu_configured()
and use them from the two default_advmss() paths.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: 164a5e7ad531 ("ipv4: ipv4_default_advmss() should use route mtu")
Cc: stable@vger.kernel.org
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260815070413.294559-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/task-analyzer.py')
0 files changed, 0 insertions, 0 deletions
