On Mon, May 4, 2026 at 7:53 AM Ankit Jain <[email protected]> wrote: > > Add a packetdrill test to verify that TCP does not aggressively penalize > the `scaling_ratio` when an application explicitly locks the receive > buffer via SO_RCVBUF. > > This test establishes a connection with a very small MSS, then injects > small payloads. On buggy kernels, the payload-to-truesize memory penalty > drops the `scaling_ratio` to 1, which shrinks the dynamically calculated > window and causes Silly Window Syndrome (SWS). > > The test asserts that `tcpi_rcv_ssthresh` (the exposed window clamp) > remains protected and stays at a healthy level. > > Signed-off-by: Ankit Jain <[email protected]> > --- > .../net/packetdrill/tcp_locked_rcvbuf_sws.pkt | 34 +++++++++++++++++++ > 1 file changed, 34 insertions(+) > create mode 100644 > tools/testing/selftests/net/packetdrill/tcp_locked_rcvbuf_sws.pkt > > diff --git > a/tools/testing/selftests/net/packetdrill/tcp_locked_rcvbuf_sws.pkt > b/tools/testing/selftests/net/packetdrill/tcp_locked_rcvbuf_sws.pkt > new file mode 100644 > index 000000000000..96d3a0813548 > --- /dev/null > +++ b/tools/testing/selftests/net/packetdrill/tcp_locked_rcvbuf_sws.pkt > @@ -0,0 +1,34 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Test that TCP does not apply aggressive truesize penalties > +// to the scaling_ratio when the application has explicitly locked > +// the receive buffer, preventing Silly Window Syndrome. > + > +// 1. Create a socket and lock SO_RCVBUF to 32K > +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 > ++0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0 > ++0 bind(3, ..., ...) = 0 > ++0 listen(3, 1) = 0 > + > +// 2. Establish connection with a TINY MSS (48 bytes) > +// This forces the kernel's rcv_mss expectation to initialize at rock bottom. > ++0 < S 0:0(0) win 65535 <mss 48,nop,wscale 8> > ++0 > S. 0:0(0) ack 1 <...> > ++0 < . 1:1(0) ack 1 win 65535 > ++0 accept(3, ..., ...) = 4 > + > +// 3. Inject 100 bytes. > +// 100 is > 48, so this forces tcp_measure_rcv_mss() to recalculate the > scaling ratio. > +// Because the payload (100B) is small compared to the sk_buff truesize, > +// kernels without the fix will incorrectly drop the scaling_ratio. > ++0.1 < P. 1:101(100) ack 1 win 65535 > ++0 > . 1:1(0) ack 101 <...> > + > +// 4. Inject 110 bytes to bypass the length jitter optimization and force > +// a second recalculation, driving the scaling_ratio to 1 and crushing the > clamp. > ++0.1 < P. 101:211(110) ack 1 win 65535 > ++0 > . 1:1(0) ack 211 <...> > + > +// 5. Assert the window clamp (tcpi_rcv_ssthresh) is protected from the > penalty. > ++0.1 %{ > +assert tcpi_rcv_ssthresh > 15000, f"BUG DETECTED: scaling_ratio crushed! > rcv_ssthresh={tcpi_rcv_ssthresh}" > +}%
I do not see the SWS effect you want to avoid in the first place. This test is an ad-hoc test about your change, but I still do not see why recomputing tp->ratio every time the rcvmss is increased is an issue on loopback interface.
