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:	Sat, 08 Aug 2009 18:28:10 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Ondrej Zary <linux@...nbow-software.org>, tglx@...utronix.de,
	mingo@...hat.com, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] OOPS in identify_cpu() on CPUs without CPUID

On 08/08/2009 10:53 AM, Ingo Molnar wrote:
> 
> indeed ...
> 
>> Signed-off-by: Ondrej Zary <linux@...nbow-software.org>
>>
>> --- linux-2.6.30.4-orig/arch/x86/kernel/cpu/common.c	2009-06-10 05:05:27.000000000 +0200
>> +++ linux-2.6.30.4-router/arch/x86/kernel/cpu/common.c	2009-08-08 18:00:21.000000000 +0200
>> @@ -699,6 +699,7 @@
>>  
>>  static void __cpuinit generic_identify(struct cpuinfo_x86 *c)
>>  {
>> +	this_cpu = &default_cpu;
>>  	c->extended_cpuid_level = 0;
>>  
>>  	if (!have_cpuid_p())
> 
> How about initializing this_cpu instead, via:
> 
> static const struct cpu_dev *this_cpu __cpuinitdata = &default_cpu;
> 

The whole this_cpu hack is scary as all hell... although it's probably
OK on a technicality, it takes what is properly a per-cpu attribute and
turns it into a static global.

We *should* be able to initialize the APs (at least) in parallel, and
although there probably aren't any systems in the field which don't have
duplicate vendors, it is at least theoretically possible to have
combinations of CPUID and non-CPUID processors in the same systems.

As such, it really would be better if this_cpu was changed to be passed
as return values and on the stack (as appropriate).  However, that is
not 2.6.31 material, and as such doing the static initialization would
be okay.

Ondrej, would you be interested in doing a "fullblown" patch for this?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ