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, 1 Sep 2008 10:11:25 +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 Sat, 30 Aug 2008, Dâniel Fraga wrote:

> On Fri, 29 Aug 2008 16:07:04 +0300 (EEST)
> "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:
> 
> > ...as it would probably not be wise to make a full dump available (that it 
> > would contain every syscall). Alternatively, you can create one full dump 
> > for yourself and just grep the relevant parts. There may be need to strace
> > more than one process (all dovecot related).
> 
> 	While waiting for a stall, I was thinking here: is there any
> chance it could be a bug generated by gcc 4.3? I saw the date gcc 4.3.0
> was released and it's just after 2.6.24 and before 2.6.25...
> 
> 	I was using gcc 4.3.1 and now 4.3.2... but maybe I could try go
> back to gcc 4.2.4 to test...

That's one option. If you do that, you could try catching two flies at the 
same time by selecting something else than tickless.

> 	Which version of gcc you developers are using?

I guess that on x86 most use some recent/semi-recent by default but there 
are some with old as well, while the non-x86 archs tend to have more often 
a bit older gccs I guess.

Anyway, if gcc did something wrong, it is still mostly correct, ie., 
there's just some race (which is likely non-corrupting even). And hitting 
that might not be very easy for some of the devs.

-- 
 i.