netdev - Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 11 Sep 2008 16:44:20 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	"Dâniel Fraga" <fragabr@...il.com>
cc:	David Miller <davem@...emloft.net>, thomas.jarosch@...ra2net.com,
	billfink@...dspring.com, Netdev <netdev@...r.kernel.org>,
	Patrick Hardy <kaber@...sh.net>,
	netfilter-devel@...r.kernel.org, kadlec@...ckhole.kfki.hu
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

On Mon, 8 Sep 2008, Dâniel Fraga wrote:

> On Mon, 8 Sep 2008 13:27:43 +0300 (EEST)
> "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:
> 
> > It could well be possible, accept seems to call schedule_timeout if 
> > nothing is immediately available (but I don't know well enough what 
> > end up being hrtimer'ed when you enable them and what will not)... 
> > Anyway, how long did you test for that to confirm it?
> 
> 	It has been five days since I disable high resolution timer and
> have not got any problems anymore.
> 
> > Does this explain the 2.6.24->2.6.25 change in behavior as well (ie., 
> > did they got enabled there)?
> 
> 	Well, as far as I know, high res timer related, what changed
> in 2.6.25 is the following:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8f4d37ec073c17e2d4aa8851df5837d798606d6f
> 
> 	(although if I disable dynticks, the problem persists)
> 
> 	Although in 2.6.24 we already had, for example the x86-32/64
> arch reunification and I don't know if it has anything to do with my
> problem in 2.6.25... just some thoughts... I wrote that because the
> problem doesn't happen in 32 bit machines, but only in x86_64...
>
> 	Of course I'm not saying for sure that the high res timer is
> causing this. Maybe, as you said before, the problem is much more
> complex and realy don't know what in fact uses high res timer.
> 
> 	Anyway, I'll leave high res timer disabled for now until we
> discover something new.

...I guess it would be possible to remove SCHED_FEAT_HRTICK from
/proc/sys/kernel/sched_features then while keeping the hrtimers
otherwise enabled to test this.

It's possible that hrtimers just affect on how easy it is to trigger
but at least it seems an useful lead until proven otherwise.


-- 
 i.