[lkml]   [2006]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: the creation of boot_cpu_init() is wrong and accessing uninitialised data
    On Mon, 26 Jun 2006 22:36:32 -0500
    James Bottomley <> 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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-27 07:08    [W:0.022 / U:11.920 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site