public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: passt-dev@passt.top
Cc: Jon Maloy <jmaloy@redhat.com>,
	Paul Holzinger <pholzing@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: [PATCH v4 1/8] tcp: FIN flags have to be retransmitted as well
Date: Tue,  9 Sep 2025 20:16:48 +0200	[thread overview]
Message-ID: <20250909181655.2990223-2-sbrivio@redhat.com> (raw)
In-Reply-To: <20250909181655.2990223-1-sbrivio@redhat.com>

If we're retransmitting any data, and we sent a FIN segment to our
peer, regardless of whether it was received, we obviously have to
retransmit it as well, given that it can only come with the last data
segment, or after it.

Unconditionally clear the internal TAP_FIN_SENT flag whenever we
re-transmit, so that we know we have to send it again, in case.

Reported-by: Paul Holzinger <pholzing@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
---
 tcp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tcp.c b/tcp.c
index 253cdb3..9b7a9b0 100644
--- a/tcp.c
+++ b/tcp.c
@@ -1778,6 +1778,7 @@ static int tcp_data_from_tap(const struct ctx *c, struct tcp_tap_conn *conn,
 			   "fast re-transmit, ACK: %u, previous sequence: %u",
 			   max_ack_seq, conn->seq_to_tap);
 		conn->seq_to_tap = max_ack_seq;
+		conn->events &= ~TAP_FIN_SENT;
 		if (tcp_set_peek_offset(conn, 0)) {
 			tcp_rst(c, conn);
 			return -1;
@@ -2312,6 +2313,7 @@ void tcp_timer_handler(const struct ctx *c, union epoll_ref ref)
 			flow_dbg(conn, "ACK timeout, retry");
 			conn->retrans++;
 			conn->seq_to_tap = conn->seq_ack_from_tap;
+			conn->events &= ~TAP_FIN_SENT;
 			if (!conn->wnd_from_tap)
 				conn->wnd_from_tap = 1; /* Zero-window probe */
 			if (tcp_set_peek_offset(conn, 0)) {
-- 
@@ -1778,6 +1778,7 @@ static int tcp_data_from_tap(const struct ctx *c, struct tcp_tap_conn *conn,
 			   "fast re-transmit, ACK: %u, previous sequence: %u",
 			   max_ack_seq, conn->seq_to_tap);
 		conn->seq_to_tap = max_ack_seq;
+		conn->events &= ~TAP_FIN_SENT;
 		if (tcp_set_peek_offset(conn, 0)) {
 			tcp_rst(c, conn);
 			return -1;
@@ -2312,6 +2313,7 @@ void tcp_timer_handler(const struct ctx *c, union epoll_ref ref)
 			flow_dbg(conn, "ACK timeout, retry");
 			conn->retrans++;
 			conn->seq_to_tap = conn->seq_ack_from_tap;
+			conn->events &= ~TAP_FIN_SENT;
 			if (!conn->wnd_from_tap)
 				conn->wnd_from_tap = 1; /* Zero-window probe */
 			if (tcp_set_peek_offset(conn, 0)) {
-- 
2.43.0


  reply	other threads:[~2025-09-09 18:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-09 18:16 [PATCH v4 0/8] tcp: Fixes for issues uncovered by tests with 6.17-rc1 kernels Stefano Brivio
2025-09-09 18:16 ` Stefano Brivio [this message]
2025-09-09 18:16 ` [PATCH v4 2/8] tcp: Factor sequence rewind for retransmissions into a new function Stefano Brivio
2025-09-09 18:16 ` [PATCH v4 3/8] tcp: Rewind sequence when guest shrinks window to zero Stefano Brivio
2025-09-10  2:20   ` David Gibson
2025-09-10  6:37     ` Stefano Brivio
2025-09-10  7:18       ` David Gibson
2025-09-10 23:48   ` Jon Maloy
2025-09-09 18:16 ` [PATCH v4 4/8] tcp: Fix closing logic for half-closed connections Stefano Brivio
2025-09-09 18:16 ` [PATCH v4 5/8] tcp: Don't try to transmit right after the peer shrank the window to zero Stefano Brivio
2025-09-09 18:16 ` [PATCH v4 6/8] tcp: Cast operands of sequence comparison macros to uint32_t before using them Stefano Brivio
2025-09-10  2:21   ` David Gibson
2025-09-09 18:16 ` [PATCH v4 7/8] tcp: Fast re-transmit if half-closed, make TAP_FIN_RCVD path consistent Stefano Brivio
2025-09-10  2:27   ` David Gibson
2025-09-10  9:57     ` Stefano Brivio
2025-09-09 18:16 ` [PATCH v4 8/8] tcp: Don't send FIN segment to guest yet if we have pending unacknowledged data Stefano Brivio
2025-09-10  2:29   ` David Gibson
2025-09-10  6:37     ` Stefano Brivio
2025-09-10  9:10 ` [PATCH v4 0/8] tcp: Fixes for issues uncovered by tests with 6.17-rc1 kernels Paul Holzinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250909181655.2990223-2-sbrivio@redhat.com \
    --to=sbrivio@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=jmaloy@redhat.com \
    --cc=passt-dev@passt.top \
    --cc=pholzing@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).