linux-kernel - Re: Linux 2.6.27.27

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: <alpine.LFD.2.01.0907201650570.19335@localhost.localdomain>
Date:	Mon, 20 Jul 2009 16:56:43 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Marc Dionne <marc.c.dionne@...il.com>
cc:	Krzysztof Oledzki <olel@....pl>, Greg KH <gregkh@...e.de>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, stable@...nel.org,
	lwn@....net
Subject: Re: Linux 2.6.27.27

On Mon, 20 Jul 2009, Marc Dionne wrote:
> 
> I might be seeing a slightly different bug, but in case it's helpful, the
> behaviour here on Fedora rawhide with gcc-4.4.0-14.x86_64 and
> binutils-2.19.51.0.11-27.fc12.x86_64 is that I get various .o files that come
> out as completely empty files (or in one case as a precisely 64K sized file
> that gives a "File format not recognized" error"), and the latest 2.6.31-rc
> git can't be built at all.

Hmm. This sounds more like the binutils bug that people had. Sounds like 
an assembler bug if the *.o file ends up being empty or at some fixed 
size. If it was cc1 that fails, I'd expect to not see an *.o file at all, 
since it didn't generate good assembly.

In fact, your behavior sounds like the thing that produces the *.o files 
core-dumped or died for other reasons, and had a 64kB buffer that either 
got flushed or not. That would explain the "zero or exactly 64kB" size.

It could be ccache too, of course. 

> If I replace -fno-strict-overflow with -fwrapv in Makefile everything builds
> and runs fine.

.. and this is just really really odd. If it was the cc1 front-end that 
does that with a bad optimization, I'd expect more visible turds. But on 
the other hand, if it's the binutils, then I don't see why -fwrapv would 
matter. Some front-end options get passed down to the assembler, but I 
would definitely not expect -fwrapv/-fno-strict-overflow to be one of 
those.

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