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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 8 Sep 2008 17:20:43 -0300
From:	Dâniel Fraga <fragabr@...il.com>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
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 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.
	
-- 
--
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