linux-kernel - 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]

Message-ID: <1432663992.4060.286.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Tue, 26 May 2015 11:13:12 -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 13:55 -0400, Ido Yariv wrote:
> Hi Eric,
> 

> 
> I understand, and I also suspect that having it expire after 9ms will
> have very little impact, if at all.
> 
> Since it mainly affects HZ=100 systems, we can simply go with having at
> least 2 jiffies on these systems, and leave everything else as is.
> 
> However, if the 10ms has a special meaning (couldn't find reasoning for
> it in the RFC), making sure this timer doesn't expire prematurely could
> be beneficial. I'm afraid this was not tested on the setup mentioned
> above though.
> 


RFC did not explain how 10ms delay was implemented. This is the kind of
dark side. RFC are full of 'unsaid things', like OS bugs.

What is not said in TLP paper is : linux timers have a 'jiffie'
granularity that might be 1/100, 1/250, 1/1000, or even 1/64 on Alpha
processors...

Fact is : We did TLP implementation and experimentations and paper at
the same time, and we do not want to change the current behavior on
HZ=1000 hosts. This is the kind of change that would require lot of
tests for Google. 

Please resend your patch so that only HZ <= 100 is changed, we will
happily acknowledge it.

Thanks


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/