Re: [PATCH RFC net-next 1/4] tcp: implement RFC 7323 window retraction receiver requirements

[Simon Baatz <gmbnomis@gmail.com>]

On Wed, Feb 25, 2026 at 10:33:34PM +0100, Stefano Brivio wrote:
> On Tue, 24 Feb 2026 19:07:45 +0100
> Simon Baatz <gmbnomis@gmail.com> 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 <devnull+gmbnomis.gmail.com@kernel.org> wrote:
> > >   
> > > > From: Simon Baatz <gmbnomis@gmail.com>
> > > > 
> > > > 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/20240406182107.261472-3-jmaloy@redhat.com/
> 
> but it was not really fixed. Anyway:

Didn't that result in 8c670bdfa58e ("tcp: correct handling of extreme
memory squeeze")?

> [...] 

-- 
Simon Baatz <gmbnomis@gmail.com>