Re: the creation of boot_cpu_init() is wrong and accessing uninitialised data

[ebiederm@xmission.com (Eric W. Biederman)]

James Bottomley <James.Bottomley@SteelEye.com> writes:

> On Sun, 2006-07-02 at 08:52 -0600, Eric W. Biederman wrote:
>> What is the point of using a non-zero logical cpu id?
>> I don't care about the apic id or the equivalent.
>
> Logical CPUs were just an artifact to get dense CPU maps, which is now
> no longer necessary.  There are architectures which have never used
> logical CPUs.  For them, the boot CPU is whatever the BIOS says it is.

So for the patch mentioned earlier in the thread I have no problems.
And I think it makes sense for arch independent code not to care.

But for x86 I am much less convinced.

>> There are cases like machine_shutdown where we care about who
>> the boot cpu is so we can reboot on that cpu.
>
> That's not at all safe:  one of the standard times for CPUs to be
> deconfigured is on boot.  It's really not a good idea to rely on finding
> the same CPU back again to boot on.

You mean besides the fact that the MPspec requires it and reboots
become much more reliable when you do because you don't tickle BIOS bugs?
It is safe because we don't do it if the cpu is not online.

>> As far as I know 
>> the kernel has not abstraction to describe the boot cpu
>> except for giving it logical cpu id 0.  Has an abstraction
>> been added that I'm not aware of?
>
> The kernel has never had an abstraction requiring logical CPUs, let
> alone one requiring that the boot CPU be numbered zero.

x86 cares, and has such code.  Now possibly that is just the generic
subarch, and voyager does not share that code.  But since the
subarch/arch code division is almost invisible on x86 it's hard to say.

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