Messages in this thread | | | Date | Mon, 26 Jun 2006 20:04:33 -0700 | From | Andrew Morton <> | Subject | Re: the creation of boot_cpu_init() is wrong and accessing uninitialised data |
| |
On Mon, 26 Jun 2006 21:45:13 -0500 James Bottomley <James.Bottomley@SteelEye.com> wrote:
> The basic problem with this function is that on most architectures > smp_processor_id() is an alias for current_thread_info()->cpu which > isn't given its correct value until setup_arch(), so adding a > boot_cpu_init() that uses it *before* setup_arch() is called is plain > wrong. You manage to get away with it 99% of the time because its > uninitialised value is zero and mostly the id of the booting CPU is > zero ... but guess who's got a box currently booting on CPU 1 with no > CPU 0?
preexisting bug, really. printk() uses smp_processor_id(). Things like spin_lock() will probably do so in certain debug modes. We finally got caught.
> Unfortunately, I can't think of a good solution for what you want to do. > The thing that looks most plausible is hard_smp_processor_id() which > reads the actual register value of the processor id. However, on x86 > (and any other architectures that renumber their CPUs in setup_arch()) > this will ultimately turn out wrong again.
I think arch code should do it before calling start_kernel(), really. It's just such a basic part of the kernel framework.
A less wholesome but perhaps simpler solution would be to call the new setup_smp_processor_id() on entry to start_kernel().
- 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/
| |