linux-kernel - Re: [BUG] x86 kenel won't boot under Virtual PC

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.1.10.0809081000490.3117@nehalem.linux-foundation.org>
Date:	Mon, 8 Sep 2008 10:04:02 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	"H. Peter Anvin" <hpa@...or.com>, linux@...dersweb.net,
	linux-kernel@...r.kernel.org,
	the arch/x86 maintainers <x86@...nel.org>,
	Andi Kleen <andi-suse@...stfloor.org>
Subject: Re: [BUG] x86 kenel won't boot under Virtual PC

On Mon, 8 Sep 2008, Andi Kleen wrote:
>
> Originally it was an option because the 128 byte cache line it selects
> caused bloat in several important data structures. That was back
> then when cache line padded NR_CPUs arrays were still pretty common.
> I don't know if it's still a problem, but before making it default y
> it would be good to check the dynamic+static memory cost at least.

Btw, I do think that the whole NOPL issue is separate from all the other 
issues. There can be _other_ cases where it really is worth doing some 
"generic" optimizations or being more "specific", and my argument really 
is that NOPL is _not_ one of those cases.

So I'm still not sure that X86_GENERIC is necessarily the answer. The 
answer may be:

 - never use NOPL statically unless we _know_ it works (eg x86-64)

 - never allow such a stupid decision by gcc as to use NOPL on x86-32.

..and then leave X86_GENERIC alone wrt everything else.

Peter - does gcc actually use NOPL in _32-bit_ code too? It really seems 
to be a stupid decision to make a binary not run on other CPU's over 
something as trivial as that. That's something I'd expect out of an Intel 
compiler just to mess with AMD, not out of gcc.

			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/