public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: passt-dev@passt.top, Stefano Brivio <sbrivio@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Subject: [PATCH 2/2] tcp: Eliminate FIN_TIMEOUT
Date: Thu, 29 Jan 2026 16:53:55 +1100	[thread overview]
Message-ID: <20260129055355.1229700-3-david@gibson.dropbear.id.au> (raw)
In-Reply-To: <20260129055355.1229700-1-david@gibson.dropbear.id.au>

From the name, and it's value of 60s, FIN_TIMEOUT appears to be defined
as an equivalent to the kernel's net.ipv4.tcp_fin_timeout sysctl, which
controls how long the kernel will keep an orphaned (that is, closed by
userspace) socket which is in FIN_WAIT_2 state.

The theory of operation describes FIN_TIMEOUT thus:

- FIN_TIMEOUT: if a FIN segment was acknowledged by tap/guest and a FIN
  segment (write shutdown) was sent via socket (events SOCK_FIN_SENT and
  TAP_FIN_ACKED), but no socket activity is detected from the socket within
  this time, reset the connection

This description does not match what net.ipv4.tcp_fin_timeout does.  The
test for SOCK_FIN_SENT does not check if we are in FIN_WAIT_2 or for an
orphaned socket.  In fact SOCK_FIN_SENT means we *cannot* be in FIN_WAIT_2
state (w.r.t. the tap side): we set it when we shutdown(SHUT_WR) the socket
connection.  We do that only when we receive a FIN from the tap side, and
the TCP state diagram does not allow us to be in FIN_WAIT_2 state if we
already have a FIN from our peer.

The description also doesn't match what the code does: in tcp_timer_ctl()
we only set FIN_TIMEOUT on our timer when when ACK_FROM_TAP_DUE is unset,
but we only act on the FIN_TIMEOUT if ACK_FROM_TAP_DUE *is* set.

In fact it's impossible for us to implement something like
net.ipv4.tcp_fin_timeout, because recognizing an orphaned socket requires
out of band information (the fact the socket has been closed) that an
endpoint kernel has, but is not visible to us (via either tap or socket
interface).  Therefore, entirely remove the FIN_TIMEOUT related logic.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 tcp.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/tcp.c b/tcp.c
index dbfde2e0..0be871a4 100644
--- a/tcp.c
+++ b/tcp.c
@@ -190,11 +190,6 @@
  * - RTO_INIT_AFTER_SYN_RETRIES: if SYN retries happened during handshake and
  *   RTO is less than this, re-initialise RTO to this for data retransmissions
  *
- * - FIN_TIMEOUT: if a FIN segment was acknowledged by tap/guest and a FIN
- *   segment (write shutdown) was sent via socket (events SOCK_FIN_SENT and
- *   TAP_FIN_ACKED), but no socket activity is detected from the socket within
- *   this time, reset the connection
- *
  * - ACT_TIMEOUT, in the presence of any event: if no activity is detected on
  *   either side, the connection is reset
  *
@@ -341,7 +336,6 @@ enum {
 
 #define RTO_INIT			1		/* s, RFC 6298 */
 #define RTO_INIT_AFTER_SYN_RETRIES	3		/* s, RFC 6298 */
-#define FIN_TIMEOUT			60
 #define ACT_TIMEOUT			7200
 
 #define LOW_RTT_TABLE_SIZE		8
@@ -594,8 +588,6 @@ static void tcp_timer_ctl(const struct ctx *c, struct tcp_tap_conn *conn)
 			timeout = MAX(timeout, RTO_INIT_AFTER_SYN_RETRIES);
 		timeout <<= MAX(exp, 0);
 		it.it_value.tv_sec = MIN(timeout, c->tcp.rto_max);
-	} else if (CONN_HAS(conn, SOCK_FIN_SENT | TAP_FIN_ACKED)) {
-		it.it_value.tv_sec = FIN_TIMEOUT;
 	} else {
 		it.it_value.tv_sec = ACT_TIMEOUT;
 	}
@@ -715,9 +707,6 @@ void conn_event_do(const struct ctx *c, struct tcp_tap_conn *conn,
 			flow_hash_remove(c, TAP_SIDX(conn));
 		tcp_epoll_ctl(conn);
 	}
-
-	if (CONN_HAS(conn, SOCK_FIN_SENT | TAP_FIN_ACKED))
-		tcp_timer_ctl(c, conn);
 }
 
 /**
@@ -2590,9 +2579,6 @@ void tcp_timer_handler(const struct ctx *c, union epoll_ref ref)
 				conn_flag(c, conn, SYN_RETRIED);
 				tcp_timer_ctl(c, conn);
 			}
-		} else if (CONN_HAS(conn, SOCK_FIN_SENT | TAP_FIN_ACKED)) {
-			flow_dbg(conn, "FIN timeout");
-			tcp_rst(c, conn);
 		} else if (conn->retries == TCP_MAX_RETRIES) {
 			flow_dbg(conn, "retransmissions count exceeded");
 			tcp_rst(c, conn);
-- 
2.52.0


  parent reply	other threads:[~2026-01-29  5:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-29  5:53 [PATCH 0/2] Fix errors in FIN timeout logic David Gibson
2026-01-29  5:53 ` [PATCH 1/2] tcp: Retransmit FINs like data segments David Gibson
2026-01-29  5:53 ` David Gibson [this message]
2026-01-29 17:33   ` [PATCH 2/2] tcp: Eliminate FIN_TIMEOUT Stefano Brivio
2026-01-30  0:56     ` David Gibson

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=20260129055355.1229700-3-david@gibson.dropbear.id.au \
    --to=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@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).