Skip to contentSkip to conversation

fix slab allocator for non zero boot cpu

PATCH In review Anton Blanchard 2 participants 2 messages Nov 5, 2002 Memory management

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 fix slab allocator for non zero boot cpu

Hi,

The slab allocator doesnt initialise ->array for all cpus. This means we fail to boot on a machine with boot cpu != 0. I was testing current 2.5 BK.

Luckily Rusty was at hand to explain the ins and outs of initialisers to me. Manfred, does this look OK to you?

Anton

===== mm/slab.c 1.46 vs edited =====

mm/slab.c +2 -1
@@ -437,7 +437,8 @@
 /* internal cache of cache description objs */
 static kmem_cache_t cache_cache = {
 	.lists		= LIST3_INIT(cache_cache.lists),
-	.array		= { [0] = &initarray_cache.cache },
+	/* Allow for boot cpu != 0 */
+	.array		= { [0 ... NR_CPUS-1] = &initarray_cache.cache },
 	.batchcount	= 1,
 	.limit		= BOOT_CPUCACHE_ENTRIES,
 	.objsize	= sizeof(kmem_cache_t),
#1 lore raw
Quoted 9 lines · Anton Blanchard

Hi,

The slab allocator doesnt initialise ->array for all cpus. This means we fail to boot on a machine with boot cpu != 0. I was testing current 2.5 BK.

Luckily Rusty was at hand to explain the ins and outs of initialisers to me. Manfred, does this look OK to you?

I don't like the patch - it removes the safety net.

initarray_cache is __initdata, and is replaced with actual data after the kmalloc caches work, but only for the cpu that performed the bootstrap (end of kmem_cache_sizes_init())

With your patch, the pointer to the head arrays of the other cpus still point to an __initdata variable. It's even oopsable, if a CPU_ONLINE_PREPARE is failed by another subsystem.

What about the attached patch?

--
Manfred