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] [day] [month] [year] [list]

Date:	Wed, 29 Jul 2009 08:59:05 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Pavel Machek <pavel@....cz>
cc:	Krzysztof Oledzki <olel@....pl>, Troy Moure <twmoure@...pr.net>,
	Greg KH <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, stable@...nel.org,
	lwn@....net, Ian Lance Taylor <iant@...gle.com>
Subject: Re: Linux 2.6.27.27

On Wed, 29 Jul 2009, Pavel Machek wrote:
> 
> So... we are going to just work around the gcc bug in the kernel?

Well, the gcc people hopefully will fix it in the 4.2.4 tree too.

Also, it's not exactly the first time we work around compiler bugs. We've 
done it before, I'm sure we'll do it again.

In this case, the work-around is trivial, and in many ways makes the code 
more "normal" (it's just a loop counter, might as well use an "int" for 
it), so there are no downsides to it. 

We could disallow gcc-4.2.4 entirely, of course, and have a big "this 
compiler is known to generate broken code" message and refuse to compile 
the kernel with it, but while that would be a "safer" approach, it would 
be rather user-unfriendly.

Compiler bugs happen. They're really really annoying, and nasty to track 
down. But they aren't the end of the world, and the pattern of this 
particular bug doesn't seem like it would likely trigger anywhere else.

For example, I suspect it really does need that loop induction variable to 
be 'unsigned char', and it really needs that limit to be exactly 128. It 
looks like a combination of loop optimization and broken range logic. I 
doubt it would hit in some random code that just happens to compare an 
unsigned char against 128 in general.

And using 'unsigned char' as a lop induction variable is _very_ rare. 
Which is probably why the gcc bug happened in the first place - no 
testing.

			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/