Messages in this thread | | | Date | Tue, 7 Feb 2006 16:15:41 +0100 | From | Heiko Carstens <> | Subject | Re: [PATCH] percpu data: only iterate over possible CPUs |
| |
> tree 8c30052a0d7fadec37c785a42a71b28d0a9c5fcf > parent cef5076987dd545ac74f4efcf1c962be8eac34b0 > author Eric Dumazet <dada1@cosmosbay.com> Sun, 05 Feb 2006 15:27:36 -0800 > committer Linus Torvalds <torvalds@g5.osdl.org> Mon, 06 Feb 2006 03:06:51 -0800 > > [PATCH] percpu data: only iterate over possible CPUs > > percpu_data blindly allocates bootmem memory to store NR_CPUS instances of > cpudata, instead of allocating memory only for possible cpus. > > As a preparation for changing that, we need to convert various 0 -> NR_CPUS > loops to use for_each_cpu(). > > (The above only applies to users of asm-generic/percpu.h. powerpc has gone it > alone and is presently only allocating memory for present CPUs, so it's > currently corrupting memory).
This patch is broken since it replaces several loops that iterate NR_CPUS times with for_each_cpu before cpu_possible_map is setup:
> --- a/fs/file.c > +++ b/fs/file.c > @@ -379,7 +379,6 @@ static void __devinit fdtable_defer_list > void __init files_defer_init(void) > { > int i; > - /* Really early - can't use for_each_cpu */ > - for (i = 0; i < NR_CPUS; i++) > + for_each_cpu(i) > fdtable_defer_list_init(i); > }
The old comment indicates it: called before smp_prepare_cpus gets called which sets up cpu_possible_map.
> diff --git a/kernel/sched.c b/kernel/sched.c > index f77f23f..839466f 100644 > --- a/kernel/sched.c > +++ b/kernel/sched.c > @@ -6109,7 +6109,7 @@ void __init sched_init(void) > runqueue_t *rq; > int i, j, k; > > - for (i = 0; i < NR_CPUS; i++) { > + for_each_cpu(i) { > prio_array_t *array;
Same here.
I didn't check the rest, but it looks like we end up with a bit of uninitialized stuff.
Heiko - 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/
| |