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=O7w2Ps7f; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id BA9CE5A0262 for ; Thu, 04 Jun 2026 06:41:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780548101; 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=GIOscGLmA9OvuuGHl02tQK/mReMXrDv8s0UNolFNSVQ=; b=O7w2Ps7fBtzwgitcvezR5SuMC/fXYRt6KsXMAaQPMKS7609XyoXpYB4hasAvxZ7p0ox1Ll ig+DkQ/aCRWmkUNdOYGHH/hXg6GRrKeoRMATFEYB3soouNCTNKLY3qjTyr9QaDGZkSAF7I f4BI84eoHxhFKFJD0JwF1Mc95yqRItY= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-325--ePqMEgkMYmuANyPR_aBjA-1; Thu, 04 Jun 2026 00:41:40 -0400 X-MC-Unique: -ePqMEgkMYmuANyPR_aBjA-1 X-Mimecast-MFC-AGG-ID: -ePqMEgkMYmuANyPR_aBjA_1780548099 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-46010bc0f1eso133535f8f.3 for ; Wed, 03 Jun 2026 21:41:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780548099; x=1781152899; 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=GIOscGLmA9OvuuGHl02tQK/mReMXrDv8s0UNolFNSVQ=; b=oiXxGsIHk7VWy//xb+dvzzjfaDgk6sbHbuvPbiSmjpyZdii2eoLT3g0aZWGzNoJ63t NtdLZ1xo4ckBiP4fDpiEOrgO5rB3WoRumdGw1QD83/ZVKqtPZzPim4uNafd7IlM77f+u OyYXHkofQMh0vdK3hTS/bz200Unv3E+2l9OgCUbMFvJNmWqNnIVTFju8QxLJAnoSjOzv AbExQkyNgkFnLtL3+oCP04Vm1I+6MOaU1QXhAC+AokThKt5y/qnutmkSdh3kZX0bgT8n vsUH5/UkAkjmDZLErbJjLU8/iXYKpUOt+qewSSTqCfHtw+kTSUk7plEwJTysod5M6BfG mwuQ== X-Gm-Message-State: AOJu0YwW3tC1Hc71CW0O4WZOCeNrXmzGSWW4uoRMkJvaZwWk1iePyGH3 XdGSm1KiDY/mtcGd/XqWKRPHl2fkHA/mGRmjYiAyo38b5XsLAqqtu/EORiqRLFO+1v0dqiAhb/8 ZrbUkCbTjnbepSsxxovj10EvzMZ79wGmarFux022Hxxkb8xtpn1KkZDO/Fn+bHw== X-Gm-Gg: Acq92OFa1HlGaKkRX7ygz6AxSn4NvMFDaDAXevKb2sxwHjEJ9EhqYytOCnsRrPI/gJZ AtLsarXgSxc/34+AFyDHpc4JGaycvNZJMOD67APlwRFTsMSPaZV/Z6mLr2ElbFwWz3QWKQorYxi d7ThUVBjA6/kDzqrEC+Vy3GP97cZT8WMC92EhkIm/AovOkl7NnWsuXya3qnRkEBThfz1O5htnex IQLeQFzyecCIQRnbs2InCMUnxDwaViODG7SIEfrrf7bJ9BLq4ID1M8nEEbG7dvG4A3zn0UzHN/g xweawL7tF3snYfvMj9SR5LeRPt8/98HIqpTR1INlZqDAovFy521rQmt1vp+4oQ/bFbm1yNJfs2s 8FL3Vs2ULRqNWTYHG5FRnVd3wRCqvvqgrJHzcKg4rlTE= X-Received: by 2002:a05:6000:2408:b0:45e:b2b7:1863 with SMTP id ffacd0b85a97d-460217ef094mr9351531f8f.16.1780548098854; Wed, 03 Jun 2026 21:41:38 -0700 (PDT) X-Received: by 2002:a05:6000:2408:b0:45e:b2b7:1863 with SMTP id ffacd0b85a97d-460217ef094mr9351502f8f.16.1780548098307; Wed, 03 Jun 2026 21:41:38 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f2e4004sm13148898f8f.9.2026.06.03.21.41.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 21:41:37 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 6/8] tcp_splice: Simplify / correct OUT_WAIT flag handling Message-ID: <20260604064134.478745ed@elisabeth> In-Reply-To: <20260528050213.679685-7-david@gibson.dropbear.id.au> References: <20260528050213.679685-1-david@gibson.dropbear.id.au> <20260528050213.679685-7-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: Thu, 04 Jun 2026 06:41:37 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: IZxxHNDlyBTSK2etNSgAeiSbptg2N4sDoaUDXweIX2Y_1780548099 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: GZ2PWG6GWHRWJRVMOPUPGIP345RXI2X3 X-Message-ID-Hash: GZ2PWG6GWHRWJRVMOPUPGIP345RXI2X3 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 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 Thu, 28 May 2026 15:02:11 +1000 David Gibson wrote: > We set the OUT_WAIT flag if we stop forwarding due to EAGAIN, but there's > still data in the pipe. That ensures we wake up when the output socket has > room to drain the pipe into. > > We clear the OUT_WAIT flag when we complete forwarding on an EPOLLOUT > event, but that's not quite right. Even though it's called on an EPOLLOUT, > tcp_splice_forward() could, in principle empty the pipe, but also read > enough new data from the other side to fill it again. That would set > OUT_WAIT internally, but it would be cleared after returning meaning > we could miss a necessary wakeup. The current logic in tcp_splice_sock_handler(): if (events & EPOLLOUT) { if (tcp_splice_forward(c, conn, !evsidei, now)) goto reset; conn_event(conn, ~OUT_WAIT(evsidei)); } if (events & EPOLLIN) { if (tcp_splice_forward(c, conn, evsidei, now)) goto reset; } would prevent the case you described, because if we read new data from the other side filling the pipe, we'll hit (events & EPOLLIN) and set OUT_WAIT again if needed. But there's a case this should actually fix, even though I've never seen it happening in practice: what if we *don't* read new data from the other side, and we can't empty the pipe in one EPOLLOUT shot anyway? I hadn't considered that before but if the receiver is slow enough that's probably possible. > The condition on whether we need write side wakeups is actually fairly > simple: we need them if and only if we return to the main loop with data > in the pipe. Maintain that in a single place - right after we exit the > forwarding loop in tcp_splice_forward(). > > Signed-off-by: David Gibson > --- > tcp_splice.c | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/tcp_splice.c b/tcp_splice.c > index 42902684..5f412584 100644 > --- a/tcp_splice.c > +++ b/tcp_splice.c > @@ -531,19 +531,22 @@ static int tcp_splice_forward(struct ctx *c, > conn->pending[fromsidei] += readlen > 0 ? readlen : 0; > conn->pending[fromsidei] -= written > 0 ? written : 0; > > - if (written < 0) { > - if (!conn->pending[fromsidei]) > - break; > - > - conn_event(conn, OUT_WAIT(!fromsidei)); > + if (written < 0) > break; > - } > > if (conn->events & FIN_RCVD(fromsidei) && > !conn->pending[fromsidei]) > break; > } > > + /* We need write-side wakeups if and only if we have data in the pipe to > + * drain. > + */ > + if (conn->pending[fromsidei]) > + conn_event(conn, OUT_WAIT(!fromsidei)); > + else > + conn_event(conn, ~OUT_WAIT(!fromsidei)); > + > if ((conn->events & FIN_RCVD(fromsidei)) && > !(conn->events & FIN_SENT(!fromsidei)) && > !conn->pending[fromsidei]) { > @@ -606,7 +609,6 @@ void tcp_splice_sock_handler(struct ctx *c, union epoll_ref ref, > if (events & EPOLLOUT) { > if (tcp_splice_forward(c, conn, !evsidei, now)) > goto reset; > - conn_event(conn, ~OUT_WAIT(evsidei)); > } > > if (events & (EPOLLIN | EPOLLRDHUP)) { -- Stefano