Re: [PATCH v4 7/8] tcp: Fast re-transmit if half-closed, make TAP_FIN_RCVD path consistent

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3617 bytes --]

On Tue, Sep 09, 2025 at 08:16:54PM +0200, Stefano Brivio wrote:
> We currently have a number of discrepancies in the tcp_tap_handler()
> path between the half-closed connection path and the regular one, and
> they are mostly a result of code duplication, which comes in turn from
> the fact that tcp_data_from_tap() deals with data transfers as well as
> general connection bookkeeping, so we can't use it for half-closed
> connections.
> 
> This suggests that we should probably rework it into two or more
> functions, in the long term, but for the moment being I'm just fixing
> one obvious issue, which is the lack of fast retransmissions in the
> TAP_FIN_RCVD path, and a potential one, which is the fact we don't
> handle socket flush failures.
> 
> Add fast re-transmit for half-closed connections, and handle the case
> of socket flush (tcp_sock_consume()) flush failure in the same way as
> tcp_data_from_tap() handles it.
> 
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

> ---
>  tcp.c | 42 +++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 39 insertions(+), 3 deletions(-)
> 
> diff --git a/tcp.c b/tcp.c
> index 9c70a25..5163dbf 100644
> --- a/tcp.c
> +++ b/tcp.c
> @@ -1652,6 +1652,23 @@ static int tcp_data_from_sock(const struct ctx *c, struct tcp_tap_conn *conn)
>  	return tcp_buf_data_from_sock(c, conn);
>  }
>  
> +/**
> + * tcp_packet_data_len() - Get data (TCP payload) length for a TCP packet
> + * @th:		Pointer to TCP header
> + * @l4len:	TCP packet length, including TCP header
> + *
> + * Return: data length of TCP packet, -1 on invalid value of Data Offset field
> + */
> +static ssize_t tcp_packet_data_len(const struct tcphdr *th, size_t l4len)
> +{
> +	size_t off = th->doff * 4UL;
> +
> +	if (off < sizeof(*th) || off > l4len)
> +		return -1;
> +
> +	return l4len - off;
> +}
> +
>  /**
>   * tcp_data_from_tap() - tap/guest data for established connection
>   * @c:		Execution context
> @@ -2113,9 +2130,28 @@ int tcp_tap_handler(const struct ctx *c, uint8_t pif, sa_family_t af,
>  
>  	/* Established connections not accepting data from tap */
>  	if (conn->events & TAP_FIN_RCVD) {
> -		tcp_sock_consume(conn, ntohl(th->ack_seq));
> -		tcp_update_seqack_from_tap(c, conn, ntohl(th->ack_seq));
> -		if (tcp_tap_window_update(c, conn, ntohs(th->window)))
> +		bool retr;
> +
> +		retr = th->ack && !tcp_packet_data_len(th, l4len) && !th->fin &&

Not really in scope here, but I wonder if we should log an error
and/or RST if we get a non-zero data length in this situation.

> +		       ntohl(th->ack_seq) == conn->seq_ack_from_tap &&
> +		       ntohs(th->window) == conn->wnd_from_tap;
> +
> +		/* On socket flush failure, pretend there was no ACK, try again
> +		 * later
> +		 */
> +		if (th->ack && !tcp_sock_consume(conn, ntohl(th->ack_seq)))
> +			tcp_update_seqack_from_tap(c, conn, ntohl(th->ack_seq));
> +
> +		if (retr) {
> +			flow_trace(conn,
> +				   "fast re-transmit, ACK: %u, previous sequence: %u",
> +				   ntohl(th->ack_seq), conn->seq_to_tap);
> +
> +			if (tcp_rewind_seq(c, conn))
> +				return -1;
> +		}
> +
> +		if (tcp_tap_window_update(c, conn, ntohs(th->window)) || retr)
>  			tcp_data_from_sock(c, conn);
>  
>  		if (conn->seq_ack_from_tap == conn->seq_to_tap) {
> -- 
> 2.43.0
> 

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]