Re: [PATCH net v2 2/2] selftests/net: add packetdrill test for locked SO_RCVBUF SWS

Eric Dumazet
2026-05-04T16:13:33Z

On Mon, May 4, 2026 at 7:53 AM Ankit Jain <ankit-aj.jain@broadcom.com> 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 <ankit-aj.jain@broadcom.com>
> ---
> .../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.