linux-kernel - Re: [PATCH 4/4] x86, 32-bit: Drop new_cpu

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: <510EF65D.4020602@zytor.com>
Date:	Sun, 03 Feb 2013 15:44:29 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...e.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [PATCH 4/4] x86, 32-bit: Drop new_cpu_data

On 02/03/2013 08:14 AM, Borislav Petkov wrote:
> From: Borislav Petkov <bp@...e.de>
>
> We copy it to boot_cpu_data anyway so use boot_cpu_data from the get-go.
>

Hmm... this is the only part of this patchset I feel skeptical towards. 
  Overall, a lot of the early SMP code went way out of its way to have 
zero impact on the !CONFIG_SMP case, but that was a long time ago. 
Nowadays what we really should have is cpu_data being a percpu variable 
separate from boot_cpu_data (which is really "all_cpu_data") even on UP.

Another cleanup desperately needed in this area is a bitvector for bugs 
in addition to features.  In fact, I kind of suspect we should make it 
the *same* bitvector (different words) so we cpu_has(X) works on both 
without confusion (just put the BUGS at the end; it means that if we add 
feature words the bug numbers will shift but that is okay.)

I actually mean to do this when I did the CPU feature vector stuff over 
10 years ago, but never got around to it... and it still has never 
gotten done.

The difference between bugs and features, of course, is that the former 
should be combined across CPUs with an OR whereas the latter get 
combined with an AND.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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