Messages in this thread | | | Subject | Re: the creation of boot_cpu_init() is wrong and accessing uninitialised data | From | James Bottomley <> | Date | Tue, 27 Jun 2006 22:45:34 -0400 |
| |
On Tue, 2006-06-27 at 17:04 -0700, Andrew Morton wrote: > +static void __init __attribute__((weak)) smp_setup_processor_id(void)
If you're really sure this works .. then it looks OK. However, I thought weak was a linker attribute, not a compiler one. How does the compiler know if the static inline needs to be incorporated or if a strong symbol is going to override it when the whole thing is linked together at the time it just compiles main.c?
> +{ > +} > + > asmlinkage void __init start_kernel(void) > { > char * command_line; > extern struct kernel_param __start___param[], __stop___param[]; > + > + smp_setup_processor_id(); > + > /* > * Interrupts are still disabled. Do necessary setups, then > * enable them > diff -puN arch/i386/mach-voyager/voyager_smp.c~add-smp_setup_processor_id arch/i386/mach-voyager/voyager_smp.c > --- a/arch/i386/mach-voyager/voyager_smp.c~add-smp_setup_processor_id > +++ a/arch/i386/mach-voyager/voyager_smp.c > @@ -1938,3 +1938,9 @@ smp_cpus_done(unsigned int max_cpus) > { > zap_low_mappings(); > } > + > +void __init > +smp_setup_processor_id(void) > +{ > + current_thread_info()->cpu = hard_smp_processor_id(); > +} > diff -puN include/linux/smp.h~add-smp_setup_processor_id include/linux/smp.h > --- a/include/linux/smp.h~add-smp_setup_processor_id > +++ a/include/linux/smp.h > @@ -125,4 +125,6 @@ static inline void smp_send_reschedule(i > #define put_cpu() preempt_enable() > #define put_cpu_no_resched() preempt_enable_no_resched() > > +void smp_setup_processor_id(void); > + > #endif /* __LINUX_SMP_H */ > _ > > > Note that I moved the call to smp_setup_processor_id() to be super-early. > Before the lock_kernel(), before everything. It seems better that way. > And there's lockdep init stuff in -mm which is called immediately on entry > to start_kernel() which might want to use smp_processor_id(). > > Is that all OK?
I'll give it a whirl tomorrow when I get access to one of the voyager systems in Columbia.
James
- 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/
| |