netdev - Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

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]

Date:	Tue, 26 May 2015 09:23:55 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Ido Yariv <ido@...ery.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>,
	Nandita Dukkipati <nanditad@...gle.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ido Yariv <idox.yariv@...el.com>
Subject: Re: [PATCH] net: tcp: Fix a PTO timing granularity issue

On Tue, 2015-05-26 at 10:25 -0400, Ido Yariv wrote:
> The Tail Loss Probe RFC specifies that the PTO value should be set to
> max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time.
> 
> The PTO value is converted to jiffies, so the timer might expire
> prematurely. This is especially problematic on systems in which HZ=100.
> 
> To work around this issue, increase the number of jiffies by one,
> ensuring that the timeout won't expire in less than 10ms.
> 
> Signed-off-by: Ido Yariv <idox.yariv@...el.com>
> ---
>  net/ipv4/tcp_output.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 534e5fd..6f57d3d 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2207,7 +2207,7 @@ bool tcp_schedule_loss_probe(struct sock *sk)
>  	if (tp->packets_out == 1)
>  		timeout = max_t(u32, timeout,
>  				(rtt + (rtt >> 1) + TCP_DELACK_MAX));
> -	timeout = max_t(u32, timeout, msecs_to_jiffies(10));
> +	timeout = max_t(u32, timeout, msecs_to_jiffies(10) + 1);
>  
>  	/* If RTO is shorter, just schedule TLP in its place. */
>  	tlp_time_stamp = tcp_time_stamp + timeout;

Have you really hit an issue, or did you send this patch after all these
msecs_to_jiffies() discussions on lkml/netdev ?

Not sure this is the right fix.

TLP was really tested with an effective min delay of 10ms.

Adding 10% for the sake of crazy HZ=100 builds seems a high price.
(All recent TCP changes were tested with HZ=1000 BTW ...)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 534e5fdb04c11152bae36f47a786e8b10b823cd3..5321df89af9b59c6727395c489e6f9b2770dcd5e 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2208,6 +2208,9 @@ bool tcp_schedule_loss_probe(struct sock *sk)
 		timeout = max_t(u32, timeout,
 				(rtt + (rtt >> 1) + TCP_DELACK_MAX));
 	timeout = max_t(u32, timeout, msecs_to_jiffies(10));
+#if HZ <= 100
+	timeout = max_t(u32, timeout, 2);
+#endif
 
 	/* If RTO is shorter, just schedule TLP in its place. */
 	tlp_time_stamp = tcp_time_stamp + timeout;


--
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