linux-kernel - Re: Next April 28: boot failure on PowerPC with SLQB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Apr 2009 13:36:05 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Sachin Sant <sachinp@...ibm.com>, linuxppc-dev@...abs.org,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: Next April 28: boot failure on PowerPC with SLQB

On Tue, Apr 28, 2009 at 02:22:06PM +0300, Pekka Enberg wrote:
> Nick,
> 
> Here's another one. I think we need to either fix these rather quickly
> or make SLUB the defaut for linux-next again so we don't interfere
> with other testing.
> 
>                                      Pekka
> 
> On Tue, Apr 28, 2009 at 2:10 PM, Sachin Sant <sachinp@...ibm.com> wrote:
> > Today's next tree fails to boot on variety of powerpc boxes (Power5, power6)
> >
> > Memory: 3882624k/4194304k available (8384k kernel code, 311680k reserved,
> > 2048k data, 4285k bss, 512k init)
> > Kernel panic - not syncing: kmem_cache_create(): failed to create slab
> > `kmalloc'
> >
> > Call Trace:
> > [c000000000a33c30] [c000000000011668] .show_stack+0x6c/0x16c (unreliable)
> > [c000000000a33ce0] [c000000000563c8c] .panic+0x80/0x1a8
> > [c000000000a33d70] [c0000000001410d8] .kmem_cache_open+0x4e8/0x51c
> > [c000000000a33e20] [c0000000007d90b8] .kmem_cache_init+0x264/0x35c
> > [c000000000a33ee0] [c0000000007b0b68] .start_kernel+0x404/0x51c
> > [c000000000a33f90] [c0000000000083d8] .start_here_common+0x1c/0x44

OK I think the problem is that with 64K pages you get a default MAX_ORDER
of 9, and slqb is trying to create slabs which exceed that size..

Does this help?
---

SLQB: fix slab calculation

SLQB didn't consider MAX_ORDER when defining which sizes of kmalloc
slabs to create. It panics at boot if it tries to create a cache
which exceeds MAX_ORDER-1.

Signed-off-by: Nick Piggin <npiggin@...e.de>
---
Index: linux-2.6/include/linux/slqb_def.h
===================================================================
--- linux-2.6.orig/include/linux/slqb_def.h	2009-04-29 21:27:30.000000000 +1000
+++ linux-2.6/include/linux/slqb_def.h	2009-04-29 21:28:13.000000000 +1000
@@ -172,7 +172,8 @@ struct kmem_cache {
 #endif
 
 #define KMALLOC_SHIFT_LOW ilog2(KMALLOC_MIN_SIZE)
-#define KMALLOC_SHIFT_SLQB_HIGH (PAGE_SHIFT + 9)
+#define KMALLOC_SHIFT_SLQB_HIGH ((PAGE_SHIFT + 9) < MAX_ORDER ? \
+				(PAGE_SHIFT + 9) : (MAX_ORDER - 1))
 
 extern struct kmem_cache kmalloc_caches[KMALLOC_SHIFT_SLQB_HIGH + 1];
 extern struct kmem_cache kmalloc_caches_dma[KMALLOC_SHIFT_SLQB_HIGH + 1];

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/