Date: Wed, 15 Feb 2006 15:17:16 -0800
From: Andrew Morton <akpm@osdl.org>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: frankeh@watson.ibm.com, linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: SMP BUG
Message-Id: <20060215151716.201da5de.akpm@osdl.org>
In-Reply-To: <20060215230701.GD1508@flint.arm.linux.org.uk>
References: <43F12207.9010507@watson.ibm.com>
	<20060215230701.GD1508@flint.arm.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2066
Lines: 58

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.

-
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/