From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202512 header.b=JyBhqamN; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 326305A0623 for ; Mon, 08 Dec 2025 07:43:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202512; t=1765176201; bh=O7xglBqg6fmISACfC68UTQFReHsnWhkJM+Zlf568wks=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JyBhqamNRzi3Dgpo6kGH0ewC40qYP6Iq8spUr58BnvWuXgy+u5P7JjBVi+ztW8M2P 3vbcH/tBsDnOx5Dm/HnJM4qcnrpbwmxXblVgdZsMjDqMcYsmhtvWl2KBPfuZJnwIQK JsBAtulHpobi9Fc5uEUNEuDoBFdrosuoXZvlowEKvEznrbcnWTJUslmwjuO/HEvKsJ /qtaWkDVTD+t535pLEjhLfAT095T7tZ0USAumiS0jt73v1x1YhX8rV6Rnz3mEZ5PfX uYuP7JQs3HHUHdggBpUUgHCQywEUgTw8rz+p0b08Rz3PkwE2CHqC4Yf9iKW3cETjMx krtbnRvFvAwSg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4dPsr93GXpz4wDy; Mon, 08 Dec 2025 17:43:21 +1100 (AEDT) Date: Mon, 8 Dec 2025 17:43:14 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v2 6/9] tcp: Don't limit window to less-than-MSS values, use zero instead Message-ID: References: <20251208002229.391162-1-sbrivio@redhat.com> <20251208002229.391162-7-sbrivio@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Tpqu6lj+d9R5zEsM" Content-Disposition: inline In-Reply-To: <20251208002229.391162-7-sbrivio@redhat.com> Message-ID-Hash: HCXXR2Y2Z7Y7BJHFOXBH2SMADCM6TO2L X-Message-ID-Hash: HCXXR2Y2Z7Y7BJHFOXBH2SMADCM6TO2L X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, Max Chernoff X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Tpqu6lj+d9R5zEsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 08, 2025 at 01:22:14AM +0100, Stefano Brivio wrote: > If the sender uses data clumping (including Nagle's algorithm) for > Silly Window Syndrome (SWS) avoidance, advertising less than a MSS > means the sender might stop sending altogether, and window updates > after a low window condition are just as important as they are in > a zero-window condition. >=20 > For simplicity, approximate that limit to zero, as we have an > implementation forcing window updates after zero-sized windows. > This matches the suggestion from RFC 813, section 4. >=20 > Signed-off-by: Stefano Brivio > Reviewed-by: David Gibson Looking at this again, I'm worrying if it might allow a pathalogical case here: unlikely to hit, but very bad if it did. Suppose we have: 1. A receiver that wants to consume its input in fixed largish (~64kiB) records 2. The receiver has locked its SO_RCVBUF to that record length, or only slightly more 3. The receive buf is near full - but not quite a full record's worth The receiver doesn't consume anything, because it doesn't have a full record. Its rcvbuf is near full, so its kernel advertises only a small window. We approximate that to zero, so the sender can't send anything. So, the record never gets completed and we stall completely. The solution would be to "time out" this limitation of the advertised window, not sure how complicated that would be in practice. > --- > tcp.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) >=20 > diff --git a/tcp.c b/tcp.c > index 533c8a7..3c046a5 100644 > --- a/tcp.c > +++ b/tcp.c > @@ -1155,6 +1155,23 @@ int tcp_update_seqack_wnd(const struct ctx *c, str= uct tcp_tap_conn *conn, > else > limit =3D SNDBUF_GET(conn) - (int)sendq; > =20 > + /* If the sender uses mechanisms to prevent Silly Window > + * Syndrome (SWS, described in RFC 813 Section 3) it's critical > + * that, should the window ever become less than the MSS, we > + * advertise a new value once it increases again to be above it. > + * > + * The mechanism to avoid SWS in the kernel is, implicitly, > + * implemented by Nagle's algorithm (which was proposed after > + * RFC 813). > + * > + * To this end, for simplicity, approximate a window value below > + * the MSS to zero, as we already have mechanisms in place to > + * force updates after the window becomes zero. This matches the > + * suggestion from RFC 813, Section 4. > + */ > + if (limit < MSS_GET(conn)) > + limit =3D 0; > + > new_wnd_to_tap =3D MIN((int)tinfo->tcpi_snd_wnd, limit); > } > =20 > --=20 > 2.43.0 >=20 --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --Tpqu6lj+d9R5zEsM Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmk2c4EACgkQzQJF27ox 2GcLVhAAlKb+XiVFlUWT2GW/d6DBRbEN+H8g9/FzgbpdmxaCEaQ9DFsqlMnlJw5y 16hjRhBRQBkzbA/hVVyjVtg84i5zrdeZZ2USlg/df1UTimHQy3U1SHzB1IBR4Qp7 z4t3Fg5s4lnxwN4q+42M13wabiKIxaEldRVvoith78IvNsKUB4ylACkAVnT/QYfH FEdRotFsMlGYrjv1xSyvFnGcSXjmZ11Cd6M77l4zdpluCxSvWjGEnXvAfXGoyDtw baa0BB1KDoqNO4Tebo3JeohoslZAWTwX5kZjmz3lJck5j3cWrAXdVN+svZUAvpk+ 8jGYixn/d/eLz7DJguMr8G1V7E9mJZj3+i+qdLCC93z2pwcTlzOTrdoIAraa/Ehq EwMssQU9G6ssJbz/s1pzeGjRoDeKB6CEwOD0NIF7h0gdxZWBYFkxFpoDHuTadMzK 4koCCnyean9pLGH+Ya/byslMIXyHgC4oggazBD3q7zeQgV7FjMYgSn1ASYZH23Iz pIQ6P3JqOfn6gb+hLg2EiNmDIzIZ60tivOgY5ILe9rk4Hrkui00bJKOqUo0ZKGG3 yKwuFVBAU72jZQpdWEF2JNoDLlIql9nwzPw/2I0Hg8/ZLCzgXzjPGAo3qLlqXZ4L RnvPWJu6Z8RpYUorSMazlk711plSQ4IjDc3MHj3CApPDCplEHTA= =PJJ0 -----END PGP SIGNATURE----- --Tpqu6lj+d9R5zEsM--