Messages in this thread | | | Date | Mon, 26 Jun 2006 22:03:37 -0700 | From | Andrew Morton <> | Subject | Re: the creation of boot_cpu_init() is wrong and accessing uninitialised data |
| |
On Mon, 26 Jun 2006 22:36:32 -0500 James Bottomley <James.Bottomley@SteelEye.com> wrote:
> On Mon, 2006-06-26 at 20:04 -0700, Andrew Morton wrote: > > I think arch code should do it before calling start_kernel(), really. > > It's > > just such a basic part of the kernel framework. > > Hmm ... well, getting at current_thread_info()->cpu is possible, but > nasty to audit, I would have thought (given that we're in assembler > before start_kernel is called).
Well. It's the assembly code which chose to call start_kernel(). It could call something else.
> > A less wholesome but perhaps simpler solution would be to call the new > > setup_smp_processor_id() on entry to start_kernel(). > > I was wondering about simply replacing boot_cpu_init() with > smp_prepare_boot_cpu(). By and large they do the same thing on most > archs, and mostly they don't seem to depend on setup_arch() having been > called.
That won't fix the other bugs - we're presently calling printk() prior to setup_arch(), and printk uses smp_procesor_id().
> However, introducing setup_smp_processor_id() will also work ... I'll > see if I can do it in an easy way.
It's a bit odd - I think non-zero BSPs happen a bit more often than only-on-voyager. - 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/
| |