netdev - Re: [PATCHv2 2/2] tcp: Stalling connections: Fix timeout calculation routine

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: <op.u4kh8gosp498uc@nexus>
Date:	Mon, 07 Dec 2009 13:27:42 +0100
From:	Damian Lukowski <damian@....rwth-aachen.de>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Netdev <netdev@...r.kernel.org>,
	Frederic Leroy <fredo@...rox.org>,
	David Miller <davem@...emloft.net>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Greg KH <gregkh@...e.de>
Subject: Re: [PATCHv2 2/2] tcp: Stalling connections: Fix timeout calculation
 routine

Am 07.12.2009, 13:08 Uhr, schrieb Ilpo Järvinen  
<ilpo.jarvinen@...sinki.fi>:

> On Mon, 7 Dec 2009, Damian Lukowski wrote:
>
>> This patch fixes a problem in the TCP connection timeout calculation.
>> Currently, timeout decisions are made on the basis of the current
>> tcp_time_stamp and retrans_stamp, which is usually set at the first
>> retransmission.
>> However, if the retransmission fails in tcp_retransmit_skb(),
>> retrans_stamp is not updated and remains zero. This leads to wrong
>> decisions in retransmits_timed_out() if tcp_time_stamp is larger than
>> the specified timeout, which is very likely.
>> In this case, the TCP connection dies after the first attempted
>> (and unsuccessful) retransmission.
>>
>> With this patch, tcp_skb_cb->when is used instead, when retrans_stamp
>> is not available.
>>
>> This bug has been introduced together with retransmits_timed_out()
>> in 2.6.32, as the number of retransmissions has been used for timeout
>> decisions before.
>>
>> Thanks to Ilpo Järvinen for code suggestions and Frederic Leroy for
>> testing.
>>
>> Signed-off-by: Damian Lukowski <damian@....rwth-aachen.de>
>> ---
>>  net/ipv4/tcp_timer.c |    9 ++++++++-
>>  1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
>> index 5c5f739..a9d2891 100644
>> --- a/net/ipv4/tcp_timer.c
>> +++ b/net/ipv4/tcp_timer.c
>> @@ -140,10 +140,17 @@ static bool retransmits_timed_out(const struct  
>> sock *sk,
>>  				  unsigned int boundary)
>>  {
>>  	unsigned int timeout, linear_backoff_thresh;
>> +	unsigned int start_ts;
>>
>>  	if (!inet_csk(sk)->icsk_retransmits)
>>  		return false;
>>
>> +	if (unlikely(!tcp_sk(sk)->retrans_stamp))
>> +		start_ts = TCP_SKB_CB(tcp_write_queue_head(
>> +					(struct sock *)sk))->when;
>
> Grr, a cast....

I'm a little bit confused now (not the first time :)).
Without the cast, there are a lot of compiler warnings.
Also, I remember that I have specified const in the function signature
on purpose because of other warnings.
But now, it seems to work without const and no cast ...

>
>> +	else
>> +		start_ts = tcp_sk(sk)->retrans_stamp;
>> +
>>  	linear_backoff_thresh = ilog2(TCP_RTO_MAX/TCP_RTO_MIN);
>>
>>  	if (boundary <= linear_backoff_thresh)
>> @@ -152,7 +159,7 @@ static bool retransmits_timed_out(const struct sock  
>> *sk,
>>  		timeout = ((2 << linear_backoff_thresh) - 1) * TCP_RTO_MIN +
>>  			  (boundary - linear_backoff_thresh) * TCP_RTO_MAX;
>>
>> -	return (tcp_time_stamp - tcp_sk(sk)->retrans_stamp) >= timeout;
>> +	return (tcp_time_stamp - start_ts) >= timeout;
>>  }
>>
>>  /* A write timeout has occurred. Process the after effects. */
>>
>
> Also, in here it's more useful to provide the fix as the first patch  
> (1/2)
> since it's going to stable and those people don't want the move patch
> there.

Ok, I will patch the other way round, without the cast.

Damian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html