Re: [PATCH] OOPS in identify_cpu() on CPUs without CPUID

[Ondrej Zary]

On Sunday 09 August 2009 03:28:10 H. Peter Anvin wrote:
> On 08/08/2009 10:53 AM, Ingo Molnar wrote:
> > indeed ...
> >
> >> Signed-off-by: Ondrej Zary <linux@xxxxxxxxxxxxxxxxxxxx>
> >>
> >> --- 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?

That would be too much for me. I know basically nothing about this 
initialization code.

> 	-hpa



-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/