linux-kernel - Re: [git pull] x86 fixes

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, 08 Sep 2008 11:22:24 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	x86 maintainers <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] x86 fixes

Linus Torvalds wrote:
> 
> On Mon, 8 Sep 2008, H. Peter Anvin wrote:
>>  
>>  config X86_GENERIC
>> -	bool "Generic x86 support"
>> +	bool "Generic x86 support" if EMBEDDED
> 
> Ok, so after having realized that this seems to be more about a bug with 
> gcc, I'm really not as convinced any more.
> 
> As far as I can tell, there are three issues:
> 
>  - "-mtune=core/core2/pentium4/.." is buggy in some gas/gcc versions on 
>    x86-32, and makes architectural choices.
> 
>    Any actual _released_ versions? Maybe it's just a current SVN issue?

binutils-2.18.50.0.6-5, which is the current version on Fedora 9, does this.

>    Workaround: don't use it. And yes, X86_GENERIC=y will do that, although 
>    quite frankly that seems to be dubious in itself. But quite frankly, 
>    it's a gcc bug, and we should see it as such.
> 
>    The better workaround may well be "-Wa,-mtune=generic" as you pointed 
>    out.
> 
>  - We do the CONFIG_P6_NOPL thing ourselves, and we should just stop 
>    doing that on 32-bit. There simply isn't a good enough reason to do so. 
>    I already posteed the Kconfig.cpu patch to just stop doing it.

As far as I can tell, -Wa,-mtune=generic *should* work.  It doesn't look 
to me as if cc1 will generate the long NOPs.  That one we can do 
unconditionally, of course.

>  - X86_GENERIC means _other_ things too, like doing a 128-bit cacheline 
>    just so that it won't suck horribly on P4's even if it's otherwise 
>    tuned for a good microarchitecture.
> 
> And they really do seem to be _separate_ issues. Do we really want to tie 
> these things together under X86_GENERIC? 

Well, the argument in favour would be that if you want a kernel that can 
cross between different microarchitectures, then you want the "don't 
suck horribly on any of them".  We can, of course, divide them down 
further, but is it useful?

The "ideal" way to do any of this would probably to have checkboxes for 
all the CPUs you want to support and then a drop-down box for the CPU to 
optimize for.  However, the combinatorics of that would be horrible, and 
it would be very unlikely we would avoid bugs.

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