Re: [PATCH net-next 0/7] tcp: restrict rcv_wnd and window_clamp to representable window

[Eric Dumazet]

On Wed, Apr 8, 2026 at 2:50 PM Simon Baatz via B4 Relay
<devnull+gmbnomis.gmail.com@xxxxxxxxxx> wrote:
>
> Hi,
>
> this series ensures that rcv_wnd and window_clamp do not exceed the
> maximum window size representable for the connection's window scale
> factor.
>
> This is most visible when TCP window scaling is not used for a
> connection. In that case, the advertised window is limited to 65535
> bytes, but rcv_wnd or window_clamp can still grow beyond 65535 when
> large receive buffers are used. The resulting mismatch breaks
> calculations that depend on the advertised window, such as the ACK
> decision in __tcp_ack_snd_check(), and can prevent immediate ACKs.
>
> Similar effects may also occur when window scaling is in use, e.g. if
> the application dynamically adjusts SO_RCVBUF in unusual ways or when
> the rmem sysctl parameters change during a connection’s lifetime.
>
> Summary:
>
> - Patch 1 keeps rcv_wnd capped by the (window scale-limited)
>   window_clamp at connection start.
> - Patch 3 and 6 ensure that window_clamp is limited to the
>   representable window when it is updated.
> - The other patches add packetdrill tests to verify the new behavior.
>
> A simple iperf test on a virtme-ng VM (Intel i5-7500, 4 cores,
> loopback) shows a noticeable improvement with window scaling disabled:

Explain why we should spend time reviewing patches trying to help
stacks from 2 decades ago,
risking breaking other usages.

Almost every time we change the rcvbuf logic, we introduce bugs.

Not using window scaling in 2026 and expecting "iperf improvement" is
quite something!

Out of curiosity, which legacy product is stuck in the 20th century?