From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=MQcI//tL; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id D038B5A0262 for ; Wed, 20 May 2026 22:30:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779309008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A9Km1oN7wM1WmlK8ajzPPc64kn7dFPtwcUDWlhIPk+8=; b=MQcI//tLlVtapWHGlqCJwhsuj6dVnoVLvRzicDNVZ8dUiuEjVR84VsfOxsmqffbp0pnslg uB/df3yCr51oXqNMzUqvKNvEWd4THlCgf1tn3VlUK8vy2eXYUcqlOThNXQCs7gH+VLl1Sx 1PG50ntWCx4REPR6sIDbatrtRHhdTdU= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-278-9ClbjwEcN4G4SzGhEy-9Bg-1; Wed, 20 May 2026 16:30:07 -0400 X-MC-Unique: 9ClbjwEcN4G4SzGhEy-9Bg-1 X-Mimecast-MFC-AGG-ID: 9ClbjwEcN4G4SzGhEy-9Bg_1779309006 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-43d7a5b9678so3478568f8f.2 for ; Wed, 20 May 2026 13:30:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779309006; x=1779913806; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=A9Km1oN7wM1WmlK8ajzPPc64kn7dFPtwcUDWlhIPk+8=; b=QDaDz1rmgV41ayNOPhYpM/uIVXAuffJPDr+LM3ivllCgje3UVFCrbz9BXxR1F6dfIz 2KbEgmZd0SuJ80mX3sa3fxDPYaeOg0HBaSVljjYYP1VRUXDc84GpLQJZRVX8Hy/5EQXe ocjTLcRuzwAN6XJr0dPGvKF0XoZ3PMtNQ6LObELwPY5jrhb3J/B2Jpe+jgSkZyQesb05 sYuQWCPLHO0hF2v1M2WCSsTZ0jpRIBoD0ECx6JRZ5UFo9OQjPkGq7eFLiRRajglZ4nEf nMj6I6UEvhObjODB1la4ugvlZU7Ai9kbyMzPi65hdgFMG95nWSddlClU7nEW7CRk61Kf emZw== X-Gm-Message-State: AOJu0YztUimkDh25LXqLkgzaf/Q6AYxkMmViJsUcNBF2GvPpyxV1QxVG 5r3i5eAelyu2frrPvOqhEHaNI0147GxKViaJTfps8Wox8jQIoZ6dr2ivPRW8lM7W60X4suOxMY3 KvbXi8kRg88kOxW5E86oVqmN/J19GksDLt+x02Ke4RyvT8+55NWes2A== X-Gm-Gg: Acq92OHWCgFvWyiXjOVyATl5mLBdVzkbNT5nRzVQKvD9vIrVg3BTZl7VCieL+Y++D6s 7ORxaonYC60kiEKg2H570iiT+Jb1XRHmj9l684mbzsI0ACfcJoDOFN2Tk2XydpuzSycXt7IfQxW OTyDBePgZEQc8eIaAB0atonSOGQn9BjfAOpt5xIfhFDN955xDPbiAviyfg6laNUVkIPrK+U0dI7 up4fIM7iRQOjMhFtzcsERieX4Wqb8JSgxSbdck70woitCheMwAzxLGQvVj2CmeKVGAiChvRzFCO IsY/exo48Q67xf+Dlne2IOvMhGxib7mWiGQ1/tuiogaOR28nE1Z2coX0qzuRD7Ie2Hufjt/HFLD YtS5JlosKB/yzGmFA6gct/TqsdZovgDSOwOo6qtX7+9Ho0RWMug== X-Received: by 2002:a05:600c:608b:b0:48a:58ae:9933 with SMTP id 5b1f17b1804b1-48fe61ed232mr404081085e9.18.1779309006201; Wed, 20 May 2026 13:30:06 -0700 (PDT) X-Received: by 2002:a05:600c:608b:b0:48a:58ae:9933 with SMTP id 5b1f17b1804b1-48fe61ed232mr404080695e9.18.1779309005686; Wed, 20 May 2026 13:30:05 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49033dab0besm13816645e9.15.2026.05.20.13.30.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 13:30:05 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 5/6] tcp_splice: Simplify EPOLLRDHUP / eof / FIN handling Message-ID: <20260520223003.37ceb0f8@elisabeth> In-Reply-To: <20260520130851.436931-6-david@gibson.dropbear.id.au> References: <20260520130851.436931-1-david@gibson.dropbear.id.au> <20260520130851.436931-6-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Wed, 20 May 2026 22:30:04 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: t-TrQO7y49BTJWJ4osTj9gxyRJ0bGtzgcI0Ck_KSa5U_1779309006 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: ZJ5IUOQC24HUM27OPJGHBC3BA3CWFMRF X-Message-ID-Hash: ZJ5IUOQC24HUM27OPJGHBC3BA3CWFMRF X-MailFrom: sbrivio@redhat.com 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: On Wed, 20 May 2026 23:08:50 +1000 David Gibson wrote: > There are two ways we can tell one of our sockets has received a FIN. We > can either see an EPOLLRDHUP epoll event, or we can get a zero-length read > (EOF) on the socket. We currently use both, in a mildly confusing way: > we only set the FIN_RCVD() flag based on the EPOLLRDHUP event, but then > some other close out logic is based on seeing an EOF. > > Simplify this by setting the flag based on only the EOF. To make sure we > don't miss an event if we get an EPOLLRDHUP with no data, we trigger the > forwarding path for EPOLLRDHUP as well as EPOLLIN. > > Signed-off-by: David Gibson > --- > tcp_splice.c | 14 +++++--------- > 1 file changed, 5 insertions(+), 9 deletions(-) > > diff --git a/tcp_splice.c b/tcp_splice.c > index 8fbd490f..b45f0060 100644 > --- a/tcp_splice.c > +++ b/tcp_splice.c > @@ -487,7 +487,6 @@ static int tcp_splice_forward(struct ctx *c, struct > uint8_t lowat_set_flag = RCVLOWAT_SET(fromsidei); > uint8_t lowat_act_flag = RCVLOWAT_ACT(fromsidei); > int never_read = 1; > - int eof = 0; > > while (1) { > ssize_t readlen, written; > @@ -510,7 +509,7 @@ retry: > flow_trace(conn, "%zi from read-side call", readlen); > > if (!readlen) { > - eof = 1; > + conn_event(conn, FIN_RCVD(fromsidei)); I'm not sure if I really found a concrete issue with this, but it looks a bit scary, because it changes the semantics of FIN_RCVD, which used to mean that we infer we received a FIN, regardless of whether we're done processing all data from that half of the connection. Now FIN_RCVD is only set if we actually processed all the data and we hit the end of file. The (potential) issue I see here is that we get EPOLLRDHUP, splice() returns -1 with EAGAIN in errno because we had no room in the pipe, and it would have returned 0 instead. Will we ever get our zero-sized "read" later? If not, we might have missed EPOLLRDHUP *and* the end of file. I'm not entirely sure we have guarantees in that sense from splice(). The existing implementation distinguishes between end-of-file we hit in a given iteration, and EPOLLRDHUP we might have seen at any time. That was actually intended. -- Stefano