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=202510 header.b=M7Ncnk8U; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 2D9B55A026F for ; Wed, 08 Oct 2025 02:42:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1759884176; bh=HDAqULGr2iPfHEEtlWELgnK8hlY9iRODNvcz+tZNkRw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M7Ncnk8UzqMuLIWHM2221K2qiv1923JNj0LPpGS4+QVGCakAAZxvt3eh5ieDiDqay GEEBmDv0KmaM1Zu8GtcRhzpMDgcEiAUDIgpqCiMEYYfdgc/NmVZZjhVGxwvsiF2PYz GX3HPljJTchTW3MD/yW8EZwcv9qO+xZ3B3fKTOvgqfo3d6WX7pGQsDehhIkWfuc2IJ 3EmVVqwtGAatGF2CJmIGF8MHiq2WhahJopGA/R9u0O/37eTYeN8IVDxkBCWNAxUNSP KlSV9MZUmtoBr51fpv4+f4bORWQXgsoWGZKe0RsvoEQ7ITsyi6c43vJ7SDglbCBD9A ZMZxowNy0UShQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4chDkS0VwVz4wCX; Wed, 8 Oct 2025 11:42:56 +1100 (AEDT) Date: Wed, 8 Oct 2025 11:42:32 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 1/4] tcp: Fix ACK sequence on FIN to tap Message-ID: References: <20251002000646.2136202-1-sbrivio@redhat.com> <20251002000646.2136202-2-sbrivio@redhat.com> <20251002135841.112eb4d3@elisabeth> <20251007003219.3f286b1d@elisabeth> <20251008004237.6b50cb0d@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mWyeMvP1tIH/Vl3L" Content-Disposition: inline In-Reply-To: <20251008004237.6b50cb0d@elisabeth> Message-ID-Hash: GAYVOLZ2XH4RAW4REEXX4RQNYI2UNNNI X-Message-ID-Hash: GAYVOLZ2XH4RAW4REEXX4RQNYI2UNNNI 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 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: --mWyeMvP1tIH/Vl3L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 08, 2025 at 12:42:37AM +0200, Stefano Brivio wrote: > On Tue, 7 Oct 2025 10:31:11 +1100 > David Gibson wrote: >=20 > > On Tue, Oct 07, 2025 at 12:32:19AM +0200, Stefano Brivio wrote: > > > On Fri, 3 Oct 2025 13:19:17 +1000 > > > David Gibson wrote: > > > =20 > > > > On Thu, Oct 02, 2025 at 01:58:41PM +0200, Stefano Brivio wrote: =20 > > > > > On Thu, 2 Oct 2025 12:41:08 +1000 > > > > > David Gibson wrote: > > > > > =20 > > > > > > On Thu, Oct 02, 2025 at 02:06:43AM +0200, Stefano Brivio wrote:= =20 > > > > > > > If we reach end-of-file on a socket (or get EPOLLRDHUP / EPOL= LHUP) and > > > > > > > send a FIN segment to the guest / container acknowledging a s= equence > > > > > > > number that's behind what we received so far, we won't have a= ny > > > > > > > further trigger to send an updated ACK segment, as we are now > > > > > > > switching the epoll socket monitoring to edge-triggered mode. > > > > > > >=20 > > > > > > > To avoid this situation, in tcp_update_seqack_wnd(), we set t= he next > > > > > > > acknowledgement sequence to the current observed sequence, re= gardless > > > > > > > of what was acknowledged socket-side. =20 > > > > > >=20 > > > > > > To double check my understanding: things should work if we alwa= ys > > > > > > acknowledged everything we've received. Acknowledging only wha= t the > > > > > > peer has acked is a refinement to give the guest a view that's = closer > > > > > > to what it would be end-to-end with the peer (which might impro= ve the > > > > > > operation of flow control). =20 > > > > >=20 > > > > > Right. > > > > > =20 > > > > > > We can't use that refined mechanism when the socket is closing > > > > > > (amongst other cases), because while we can get the peer acked = bytes > > > > > > from TCP_INFO, we can't get events when that changes, so we hav= e no > > > > > > mechanism to provide updates to the guest at the right time. S= o we > > > > > > fall back to the simpler method. > > > > > >=20 > > > > > > Is that correct? =20 > > > > >=20 > > > > > Also correct, yes. If you have a better idea to summarise this in= the > > > > > comment in tcp_buf_data_from_sock() let me know. =20 > > > >=20 > > > > Hm, I might. Or actually a way to reorganise the code that I think > > > > will be a bit clearer and probably allow a clearer comment too. =20 > > >=20 > > > I would keep reworks for a later moment. Right now, it's already taki= ng > > > me long enough to find a moment to investigate these issues, write th= ese > > > fixes, and test them. =20 > >=20 > > I mean... the change I'm proposing reduces lines of code (excepting > > the big new comment), makes it easier to reason about and is localised > > to the immediately surrounding code. But whatever, I don't > > particularly care about the order we do things. >=20 > Sure, I don't think that other patch is particularly complicated or > might ever become problematic at all, but, from your earlier comment > ("reorganise the code", as I mentioned the comment in > tcp_buf_data_from_sock()), I thought you wanted to rework this > particular code in tcp_buf_data_from_sock() at the same time. Yeah, I guess "reorganise" gives an impression of a wider ranging change than it actually was. > I guess it's not the case judging from your most recent reply, though. --=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 --mWyeMvP1tIH/Vl3L Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmjls3cACgkQzQJF27ox 2GdpChAAgIPt12XmqqEc3+CoxghGS/t6/5j1K/WqRN7iLUW316UGYKFYF4fDjeZT UwToAM3HpBDUUtP6zeu1ThVz9EMAn5Qk888S9RdDCqR9NhDXZ4ZJSjZI1X8dC2h3 DrO8gjiFMmkh9rz+NlAiJFHTKqMVJ084+dXs0dG9CBxnSvzGI1v6q3tkcEYFPaJP rBEZcrTGbmsuqgj7P/iRVi2LuuFnTzLwvtFC4bj16+MqW+7kBezeZHTJaBw+077g X9/j3F07SEMaPZzVoSEgSsU2F1AINrDXmPwGu1xvhi+lDsRUA043v8Yq7LsNYTxB uYccKCS6cD20fakSq1m8CqCVKRIUFepTujMM8q9ljYOh/MTeExy8WKVSxJkE77V+ 9VZF/TpQTJo7i8+lJnOufmNW31HETYCeE4eH4edjLeFz/tWLaysbwmNfinNI5qy2 DshnpUNt/zL4Eju7/YWhYWhULOK86RY/kMcc+YP5R/bE2WUcNad5C9bspfYeQQU9 QfHg+dcRhdOqwtVfrsr7958GviE4Z54ABgnbnzMvWk5c1zq1f3x1tGqlCo/qTUaC 0OyAfBTJ1y1H8AgBfGsvlm1m+yZ06RKPlAsfFd3xcs11gWQqNQFX9IgokZX0kPNn 95WNhzmw68RJYQuA3IYJbG5cfTScMuEA79H2bWahoB03wimQh2Y= =co02 -----END PGP SIGNATURE----- --mWyeMvP1tIH/Vl3L--