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=hhFvaa4V; 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 65EF15A0272 for ; Thu, 02 Oct 2025 13:58:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1759406327; 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=cR8I2YKLxN0ngXRay10aX1PbPw1lf5yRoNj7WYqzcQI=; b=hhFvaa4VyvSgzXUhKlc6B71UK4gwhRzyFUNtzZ1VyamBQOY7ZSNhLbthRQwb6vBY0VyNji cPY8I5b8Bqup9OithIZw+sJqEKa46pxEyPG/rBkq6dXxdGLUfXFtkuguGZHNmnGklgJksf fkj2JavEP870/bwV+J3WjGvangpdthI= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-5-p8foDivdPUmR3hB8SLL8dA-1; Thu, 02 Oct 2025 07:58:45 -0400 X-MC-Unique: p8foDivdPUmR3hB8SLL8dA-1 X-Mimecast-MFC-AGG-ID: p8foDivdPUmR3hB8SLL8dA_1759406325 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-3e997eb7232so324161f8f.3 for ; Thu, 02 Oct 2025 04:58:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759406324; x=1760011124; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cR8I2YKLxN0ngXRay10aX1PbPw1lf5yRoNj7WYqzcQI=; b=pZkW5aAF5q6jjF1EFxfv+tmSiIyIlTiM4IupGMvhG9tt4sPp91X8RhpAOIODWkGAf8 Vu8XgRhb/3oRH/AM9Ra2oLbm6adqxOPMcByXtrLK9WkjfZjmXfknoomUrAjimf9b+UbE 8p/ikG13x3AEByL4QQ3p+x6vLprC0ITVFWYGh1arKRRzG+s3soWxishqiJxHa8tg7mJs UGMbx2vISueI19gyZwRvw1Z77XSUlMMfRi9lY1yh9UbCgX2PGaCisLeDLIkXl1UTMdTo eA9m84qCv/DVXRfTho2SRr2S/d92/fxLCfm4LqR6P68JFg3UrsCITiUhDySg0VPj/QAd sB0A== X-Gm-Message-State: AOJu0YxK6C8DfV3obGG3PflvuDWQ28yxFarWotfi5eCf7LgpWJJuuXCk 7AnX6AsRd8NRtHKHb54s8l93aVw11BCyL/uKqp+JI7R8gjusyXxQB37Y88JekhqJHE6+mMb/bzv hOapvV/l87rFvcdXsgxSK+mOzcQAHAwDIVqEnonMZz7aRuRTCrxc+ZEy9cEnRgA== X-Gm-Gg: ASbGnct9ZVDW9l0RQMvry8LWi5JtxxcOJQGy5fIk/gV0TJUYR0JyVOu7Av0PO7PPBYg OMobH+lnBMXZewgckcRMpWbBXUQ9g2l+LJjLDpah7SPsKaqi6/pARzXeX7IErMIa7TS53UueKiF osDVwiZKKjJqP7310zYV96/EAJdR83idnQ8W0g24tS3zZ2D5qyWD+qsTKLsO+bc79WkRPOibNVZ Sk6g6sLScb/lAzBydXm3KfaYbh78AQuzIxaMrBDwyrVxRnNyoXa/vU5p51+Susq7d6eW9pme8ix fumctG6YT6bV7w3mmn5Gyn56tdyN6kjaDpbAY0/ugnosoqqODX9G/zeAiH+I0c79wDKcwZobsw= = X-Received: by 2002:a05:6000:4212:b0:3e0:c28a:abbb with SMTP id ffacd0b85a97d-425577ed47fmr5580933f8f.13.1759406323734; Thu, 02 Oct 2025 04:58:43 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEQ06gwkc/QJOAA3CIEkB8H8cSNM7322Lt/y/oH/sG8yzhFheEagWyQfTDalBViapW0SJQKNA== X-Received: by 2002:a05:6000:4212:b0:3e0:c28a:abbb with SMTP id ffacd0b85a97d-425577ed47fmr5580914f8f.13.1759406323170; Thu, 02 Oct 2025 04:58:43 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4255d8e9762sm3348600f8f.38.2025.10.02.04.58.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Oct 2025 04:58:42 -0700 (PDT) Date: Thu, 2 Oct 2025 13:58:41 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 1/4] tcp: Fix ACK sequence on FIN to tap Message-ID: <20251002135841.112eb4d3@elisabeth> In-Reply-To: References: <20251002000646.2136202-1-sbrivio@redhat.com> <20251002000646.2136202-2-sbrivio@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: JYj85Q_ZA0nTST6uSXOnUQgf0a-TE9yjkU5R3aGkQMg_1759406325 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: WLT2IVU5CNAGWCPRSZUW4YWIO2GDUF2C X-Message-ID-Hash: WLT2IVU5CNAGWCPRSZUW4YWIO2GDUF2C 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, 2 Oct 2025 12:41:08 +1000 David Gibson wrote: > On Thu, Oct 02, 2025 at 02:06:43AM +0200, Stefano Brivio wrote: > > If we reach end-of-file on a socket (or get EPOLLRDHUP / EPOLLHUP) and > > send a FIN segment to the guest / container acknowledging a sequence > > number that's behind what we received so far, we won't have any > > further trigger to send an updated ACK segment, as we are now > > switching the epoll socket monitoring to edge-triggered mode. > > > > To avoid this situation, in tcp_update_seqack_wnd(), we set the next > > acknowledgement sequence to the current observed sequence, regardless > > of what was acknowledged socket-side. > > To double check my understanding: things should work if we always > acknowledged everything we've received. Acknowledging only what 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 improve the > operation of flow control). Right. > 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 have no > mechanism to provide updates to the guest at the right time. So we > fall back to the simpler method. > > Is that correct? Also correct, yes. If you have a better idea to summarise this in the comment in tcp_buf_data_from_sock() let me know. Maybe I could mention EPOLLET explicitly there? > > However, we don't necessarily call tcp_update_seqack_wnd() before > > sending the FIN segment, which might potentially lead to a situation, > > not observed in practice, where we unnecessarily cause a > > retransmission at some point after our FIN segment. > > > > Avoid that by setting the ACK sequence to whatever we received from > > the container / guest, before sending a FIN segment and switching to > > EPOLLET. > > > > Signed-off-by: Stefano Brivio > > Based on my understanding above, this looks correct to me, so, > > Reviewed-by: David Gibson > > My only concern is whether we could instead insert an extra call to > tcp_update_seqack_wnd() to reduce duplicated logic. Hmm, maybe, but on the other hand we're closing the connection. Should we really spend time querying TCP_INFO to recalculate the window at this point? I wouldn't. > > --- > > tcp_buf.c | 14 +++++++++++++- > > tcp_vu.c | 7 ++++++- > > 2 files changed, 19 insertions(+), 2 deletions(-) > > > > diff --git a/tcp_buf.c b/tcp_buf.c > > index a493b5a..cc106bc 100644 > > --- a/tcp_buf.c > > +++ b/tcp_buf.c > > @@ -368,7 +368,19 @@ int tcp_buf_data_from_sock(const struct ctx *c, struct tcp_tap_conn *conn) > > conn_flag(c, conn, STALLED); > > } else if ((conn->events & (SOCK_FIN_RCVD | TAP_FIN_SENT)) == > > SOCK_FIN_RCVD) { > > - int ret = tcp_buf_send_flag(c, conn, FIN | ACK); > > + int ret; > > + > > + /* On TAP_FIN_SENT, we won't get further data events > > + * from the socket, and this might be the last ACK > > + * segment we send to the tap, so update its sequence to > > + * include everything we received until now. > > + * > > + * See also the special handling on CONN_IS_CLOSING() in > > + * tcp_update_seqack_wnd(). > > + */ > > + conn->seq_ack_to_tap = conn->seq_from_tap; > > + > > + ret = tcp_buf_send_flag(c, conn, FIN | ACK); > > if (ret) { > > tcp_rst(c, conn); > > return ret; > > diff --git a/tcp_vu.c b/tcp_vu.c > > index ebd3a1e..3ec3538 100644 > > --- a/tcp_vu.c > > +++ b/tcp_vu.c > > @@ -410,7 +410,12 @@ int tcp_vu_data_from_sock(const struct ctx *c, struct tcp_tap_conn *conn) > > conn_flag(c, conn, STALLED); > > } else if ((conn->events & (SOCK_FIN_RCVD | TAP_FIN_SENT)) == > > SOCK_FIN_RCVD) { > > - int ret = tcp_vu_send_flag(c, conn, FIN | ACK); > > + int ret; > > + > > + /* See tcp_buf_data_from_sock() */ > > + conn->seq_ack_to_tap = conn->seq_from_tap; > > + > > + ret = tcp_vu_send_flag(c, conn, FIN | ACK); > > if (ret) { > > tcp_rst(c, conn); > > return ret; > > -- > > 2.43.0 > > -- Stefano