On Wed, Feb 25, 2026 at 10:33:34PM +0100, Stefano Brivio wrote:
> On Tue, 24 Feb 2026 19:07:45 +0100
> Simon Baatz <[email protected]> wrote:
>
> > Hi Stefano,
> >
> > On Mon, Feb 23, 2026 at 11:26:40PM +0100, Stefano Brivio wrote:
> > > Hi Simon,
> > >
> > > It all makes sense to me at a quick look, I have just some nits and one
> > > more substantial worry, below:
> > >
> > > On Fri, 20 Feb 2026 00:55:14 +0100
> > > Simon Baatz via B4 Relay <[email protected]> wrote:
> > >
> > > > From: Simon Baatz <[email protected]>
> > > >
> > > > By default, the Linux TCP implementation does not shrink the
> > > > advertised window (RFC 7323 calls this "window retraction") with the
> > > > following exceptions:
> > > >
> > > > - When an incoming segment cannot be added due to the receive buffer
> > > > running out of memory. Since commit 8c670bdfa58e ("tcp: correct
> > > > handling of extreme memory squeeze") a zero window will be
> > > > advertised in this case. It turns out that reaching the required
> > > > "memory pressure" is very easy when window scaling is in use. In the
> > > > simplest case, sending a sufficient number of segments smaller than
> > > > the scale factor to a receiver that does not read data is enough.
> > > >
> > > > Since commit 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks") this
> > > > happens much earlier than before, leading to regressions (the test
> > > > suite of the Valkey project does not pass because of a TCP
> > > > connection that is no longer bi-directional).
> > >
> > > Ouch. By the way, that same commit helped us unveil an issue (at least
> > > in the sense of RFC 9293, 3.8.6) we fixed in passt:
> > >
> > >
> > > https://passt.top/passt/commit/?id=8d2f8c4d0fb58d6b2011e614bc7d7ff9dab406b3
> > >
> >
> > This looks concerning: It seems as if just filling the advertised
> > window triggered the out of memory condition(?).
>
> Right, even if it's not so much a general "out of memory" condition:
> it's just that the socket might simply refuse to queue more data at
> that point (we run out of window space, rather than memory).
>
> Together with commit e2142825c120 ("net: tcp: send zero-window ACK when
> no memory"), we will even get zero-window updates in that case. Jon
> raised the issue here:
>
> https://lore.kernel.org/r/[email protected]/
>
> but it was not really fixed. Anyway:
Didn't that result in 8c670bdfa58e ("tcp: correct handling of extreme
memory squeeze")?
> [...]
--
Simon Baatz <[email protected]>
