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=202602 header.b=V0QC7Ecp; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 7CC775A0269 for ; Thu, 21 May 2026 04:29:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1779330549; bh=E3T54e8w7V1urTB22HLY+suMyNyYA1e0qgusoepfXaE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V0QC7EcpvfOmlAUMkVBEVoEyvSG5PaFN8pTbxMEhuiNLbIeOfy05B0HwGHfrAJKn6 alF4isQg/q01v5HhUNvbdWNiD2tj0c21yumEFHslWyRFzoCXOUkBWojE+6HQ5acyqw 9QP4nmdE6MeKDRWUiVQF+dXaUYbqISk9CbJO6iQEJDXPjmJXBRV5lxpumQ3u2bMcZ8 nvmOWNjsLQe1SROqOmMIuuKNJwU2M3R9bRMwnGSN9R9xDQ+124zU+eCzrLs3O3NjmL S71OWH40jo3jW2T1XWKyRF7REbi/Qg5SvDzJAN8Ei3XIhyscJR67lmoZlQUQadiVcq 2xh4OyQrzsLHA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gLXR95w10z4wLM; Thu, 21 May 2026 12:29:09 +1000 (AEST) Date: Thu, 21 May 2026 10:46:24 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 2/6] tcp_splice: Avoid missing EOF recognition while forwarding Message-ID: References: <20260520130851.436931-1-david@gibson.dropbear.id.au> <20260520130851.436931-3-david@gibson.dropbear.id.au> <20260520222835.768600be@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X3CzhV7jLHnOlEuN" Content-Disposition: inline In-Reply-To: <20260520222835.768600be@elisabeth> Message-ID-Hash: BQ5ZPNC2XXCCX76HMMJMPZXGKAPJ3DJB X-Message-ID-Hash: BQ5ZPNC2XXCCX76HMMJMPZXGKAPJ3DJB 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, Paul Holzinger 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: --X3CzhV7jLHnOlEuN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 20, 2026 at 10:28:36PM +0200, Stefano Brivio wrote: > On Wed, 20 May 2026 23:08:47 +1000 > David Gibson wrote: >=20 > > tcp_splice_sock_handler() has an optimised path for the common case whe= re > > the amount we splice(2) into the pipe is exactly the same as the amount= we > > splice(2) out again. If the pipe is empty at that point, we stop > > forwarding until we get another epoll event. > >=20 > > However, via a subtle chain of events, this can cause a bug for a > > half-closed connection. Suppose the connection is already half-closed = in > > the other direction - that is, we've already called shutdown(SHUT_WR) on > > the socket for which we're getting the event. In this event we're gett= ing > > the last batch of data in the other direction, and also a FIN. This can > > result in EPOLLIN, EPOLLRDHUP and EPOLLHUP events simultaneously. > >=20 > > We read the last data from the socket and successfully splice it to the > > other side. Since there is no data in the pipe, we exit the forwarding > > loop. However, because we did read data, we don't set the eof flag. > >=20 > > Because we don't set eof, we don't (yet) propagate the FIN to the other > > side, or set FIN_SENT_(!fromsidei). Therefore we don't (yet) recognize > > this as a clean termination and set the CLOSING flag. We would correct > > this when we get our next event, however before we can do so we process > > the EPOLLHUP event. Because we haven't recognized this as a clean close > > we assume it is an abrupt close and send an RST to the other side. > >=20 > > To avoid this, don't stop attempting to forward data on this path. > > Continue for at least one more loop. If we're at EOF, we'll recognize = it > > on the next splice(2). If not it gives us an opportunity to forward mo= re > > data without returning to the mail epoll loop. >=20 > Oops. The fix looks correct to me, but I wonder: is it clear to you why > the issue only started occurring in this release? This code had "always" > been there. Because we didn't used to force resets on abnormal connection terminations, so it still worked by accident. > I see a few possible directions but I'm not quite sure. Not that > important anyway, if you could reproduce the issue and this fixes it. Ah, actually, I do still need to test with the original reproducer. It fixes it for my reproducer which I'm maybe 90% confident is exercising the same bug. > Just one nit: >=20 > > Link: https://bugs.passt.top/show_bug.cgi?id=3D202 > > Signed-off-by: David Gibson >=20 > Reported-by: Paul Holzinger Good point, fixed. >=20 > > --- > > tcp_splice.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/tcp_splice.c b/tcp_splice.c > > index 1359d6b8..34ffea73 100644 > > --- a/tcp_splice.c > > +++ b/tcp_splice.c > > @@ -605,7 +605,7 @@ retry: > > } > > } > > =20 > > - break; > > + continue; > > } > > =20 > > conn->read[fromsidei] +=3D readlen > 0 ? readlen : 0; >=20 > --=20 > Stefano >=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 --X3CzhV7jLHnOlEuN Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmoOVd8ACgkQzQJF27ox 2GcdwA//XLCpqtdpUlxbnEnv/Tl4Z6taVeAIoDCMqJeKJUmVPLYq9tgkOEYqntLH y/929IrhvD3Q61gPzDadFy339jaLvSVvqbtdOA743Ibqf5m7v6FxXDBD+kJS6Y51 nRl6QanjJ/r7sKT4Oj/b3CVJlC3+/CuN8dpQ67qnivVLrtUOYdmXLlZbcHLOTg8d CVyWJmTFxBCaTIcJwFm8My3U5TqPwKUq8uLqWpPlyW6YkpR7JlqEAmDzczgInD7u TmdOx6y7CtoQlFxfpkI4CC7LfnxiPohx7/wkyTF+0PT4KImSHUeZQFDEJyfixUA0 Iu6PuhoeJSA6wklb9uQKdBSI+v+ZxnLkduFfaoDY+c/5CtMGFgYCZJuPlsL5R735 7cjVAdoF3WDNUh6XDdcmgKwVom8ccSj6nGrjqpT/K0PRog28B3ia+OFrWHzr81VQ 2kHh4B3DJNPlpHBXVZxaVc6v3ERwxSj5XBYoi++iX2CTnbfWM12oAGVJ80+Zf/TJ 896QENYxQzJ8PfTp4Ys6lmB6ThiJE/KAY99fuw0zavAOqSnoLPvZXLtRquzy6spu qZD+QtFW+1yqwxswScvW9SJPxv0LkVbiuB1KQUtHnUyj9QNxMJtzpTRW+MIL9bK7 q77wFfM1NTvQ/i2bPZQfGXpST4wEpAFeKCa0bKzbLWw4Z377Bvw= =Lz9h -----END PGP SIGNATURE----- --X3CzhV7jLHnOlEuN--