selftests/net: packetdrill: check rcv_ssthresh vs scaling_ratio changes

tcp_measure_rcv_mss() recomputes tp->scaling_ratio from
skb->len/skb->truesize and updates tp->window_clamp accordingly. Commit
f5da7c45188e ("tcp: adjust rcvq_space after updating scaling ratio")
made that update go through tcp_set_window_clamp(), which also shrinks
tp->rcv_ssthresh, so every scaling_ratio dip cut the advertised window
as well. Commit 0e125ecfe20c ("tcp: do not change rcv_ssthresh in
tcp_measure_rcv_mss()") restored the plain window_clamp update.

Add a packetdrill test for it, as suggested during the review of that
fix. A fixed SO_RCVBUF pins sk_rcvbuf, so window_clamp can only move
when scaling_ratio does, and the peer announces TCP_MIN_MSS so that
icsk_ack.rcv_mss sits at its 88 byte floor. A single 89 byte segment is
then measured, and 89 bytes of payload in a ~900 byte skb is far below
the 50% that TCP_DEFAULT_SCALING_RATIO assumes, so scaling_ratio and
window_clamp drop sharply. Nothing puts the socket under memory
pressure, so rcv_ssthresh must not move at all.

The test checks the state it depends on instead of assuming it.
tcp_measure_rcv_mss() only measures segments of at least rcv_mss bytes,
so rcv_mss is checked to be 88 before the segment is sent. It is checked
to be 89 afterwards, because rcv_mss is only updated by the same code
that recomputes scaling_ratio, so this proves the segment was measured.
rcv_ssthresh is compared against the value it had right after the
handshake, not against a fixed number, so the test does not depend on
the receive buffer size or on how the architecture accounts skb memory.

Verified on net-next, where it passes for ipv4, ipv6 and
ipv4-mapped-ipv6, and on the same tree with the fix reverted, where it
fails in all three modes with rcv_ssthresh cut from 260684 to 51200.

Signed-off-by: Nathan Gao <zcgao@amazon.com>
Link: https://patch.msgid.link/20260918045021.42138-1-zcgao@amazon.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

0 files changed, 0 insertions, 0 deletions