linux-kernel - Re: [PATCH 01/41] rxrpc: Fix RTT determination to use PING ACKs as a source

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6fadc6aa-4078-4f12-a4c7-235267d6e0b1@auristor.com>
Date:   Thu, 9 Nov 2023 12:16:06 -0500
From:   Jeffrey E Altman <jaltman@...istor.com>
To:     David Howells <dhowells@...hat.com>,
        Marc Dionne <marc.dionne@...istor.com>
Cc:     linux-afs@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/41] rxrpc: Fix RTT determination to use PING ACKs as a
 source

On 11/9/2023 10:39 AM, David Howells wrote:
> Fix RTT determination to use a PING ACK that is in marked as being in
> response to a DATA packet as the response from which RTT can be calculated
> from in lieu of a REQUESTED ACK.  The server may send the latter instead of
> the former.
>
> Fixes: 4700c4d80b7b ("rxrpc: Fix loss of RTT samples due to interposed ACK")
> Signed-off-by: David Howells <dhowells@...hat.com>
> cc: Marc Dionne <marc.dionne@...istor.com>
> cc: linux-afs@...ts.infradead.org
> ---
>   net/rxrpc/input.c | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
> index 030d64f282f3..fc0d404f3b91 100644
> --- a/net/rxrpc/input.c
> +++ b/net/rxrpc/input.c
> @@ -806,6 +806,10 @@ static void rxrpc_input_ack(struct rxrpc_call *call, struct sk_buff *skb)
>   		rxrpc_complete_rtt_probe(call, skb->tstamp, acked_serial, ack_serial,
>   					 rxrpc_rtt_rx_ping_response);
>   		break;
> +	case RXRPC_ACK_PING:
> +		if (acked_serial == 0)
> +			break;
> +		fallthrough;
>   	case RXRPC_ACK_REQUESTED:
>   		rxrpc_complete_rtt_probe(call, skb->tstamp, acked_serial, ack_serial,
>   					 rxrpc_rtt_rx_requested_ack);

David,

I do not believe the ack_reason matters within rxrpc_input_ack(). As 
long as the acked_serial is non-zero,
rxrpc_complete_rtt_probe() can be called to attempt to compute an RTT.   
If there is an exact match for the
acked_serial then an RTT can be computed and if acked_serial is later 
than the pending rtt probe, the probe
can be abandoned with the following caveats.

 1. Receiving an acked_serial that is later than the serial of the
    transmitted probe indicates that a packet
    transmitted after the probe was received first.  Or that reordering
    of the transmitted packets occurred.
    Or that the probe was never received by the peer; or that the peer's
    response to the probe was lost in
    transit.
 2. The serial number namespace is unsigned 32-bit shared across all of
    the call channels of the associated
    rx connection.  As the serial numbers will wrap the use of after()
    within rxrpc_complete_rtt_probe to
    compare their values is questionable.   If serial numbers will be
    compared in this manner then they
    need to be locally tracked and compared as unsigned 64-bit values
    where only the low 32-bits are
    transmitted on the wire and any wire serial number equal to zero is
    ignored.

Jeffrey Altman





Download attachment "smime.p7s" of type "application/pkcs7-signature" (4039 bytes)