linux-kernel - Re: [PATCH] OOPS in identify

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] [day] [month] [year] [list]

Message-Id: <200908092312.36578.linux@rainbow-software.org>
Date:	Sun, 9 Aug 2009 23:12:33 +0200
From:	Ondrej Zary <linux@...nbow-software.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...e.hu>, 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 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@...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?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/