On Thu, 26 Feb 2026 02:10:25 +0100 Simon Baatz <[email protected]> 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 <[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")? 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
