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

[Stefano Brivio <sbrivio@redhat.com>]

On Thu, 26 Feb 2026 02:10:25 +0100
Simon Baatz <gmbnomis@gmail.com> wrote:

> 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")?

Yes, but with that (the v3 of it) we still send zero-window updates
more frequently (because of the 'return 0' instead of 'goto out') and
together with e2142825c120 I was seeing in the captures one zero-window
update almost every time the sender filled up the window completely.

Perhaps it was even desired, I'm not sure, I can't say it's entirely
wrong (that's why I didn't propose a further patch), and strictly
speaking the issue was on passt side (we didn't send window probes in
that case, and we didn't retransmit FINs).

I guess with f017c1f768b things should be sane again. I didn't check.

-- 
Stefano