Re: SMP BUG

[Andrew Morton <akpm@osdl.org>]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
> On Mon, Feb 13, 2006 at 07:19:19PM -0500, Hubertus Franke wrote:
> > Folks the change introduced in 2.6.16-rc2   over 2.6.15
> > wrt to the SMP initialization are wrong.
> > Please apply to unroll the change..
> > 
> > Here is the logic ...
> > sched_init is called from start_kernel before the
> > architecture specific function cpu_check_smp() is called
> > which is done as part of rest_init().
> > 
> > On s390 this actually sets the cpu_possible_map, which
> > is now used in sched_init through the for_each_cpu without
> > properly being initialized.
> > As a result bringing 2nd and subsequent cpu online
> > breaks.
> > 
> > This should be a quick fix, until this chicken and egg
> > problem is solved otherwise.
> > 
> > -- Hubertus
> > 
> > --- kernel/sched.c.orig 2006-02-13 19:08:28.000000000 -0500
> > +++ kernel/sched.c      2006-02-13 19:09:08.000000000 -0500
> > @@ -6111,7 +6111,7 @@ void __init sched_init(void)
> >         runqueue_t *rq;
> >         int i, j, k;
> > 
> > -       for_each_cpu(i) {
> > +       for (i = 0; i < NR_CPUS; i++ ) {
> >                 prio_array_t *array;
> > 
> >                 rq = cpu_rq(i);
> 
> (left most of the message intact because it seems to have been ignored.
> Copying Linus and akpm in the vague hope of a response.)

This has already been fixed in s390.

> Yes, I'm also seeing an oops caused by exactly this on ARM:
> 
> ...
>
> enqueue_task is being called with p = c03fe2e0, array = NULL, leading
> to a NULL pointer dereference because rq->array has not been initialised.

Is arm's setup_arch() populating cpu_possible_map?

If that's not possible, statically initialising it to CPU_MASK_ALL should
fix it, but that's a lame solution and might lead to wastage of per-cpu
memory on not-possible CPUs.