[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1223388788.26330.38.camel@lappy.programming.kicks-ass.net>
Date: Tue, 07 Oct 2008 16:13:08 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Christoph Lameter <cl@...ux-foundation.org>
Cc: Matt Mackall <mpm@...enic.com>, linux-mm <linux-mm@...ck.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] SLOB's krealloc() seems bust
On Tue, 2008-10-07 at 09:07 -0500, Christoph Lameter wrote:
> > Which basically shows us that the content of the pcpu_size[] array got
> > corrupted after the krealloc() call in split_block().
> >
> > Which made me look at which slab allocator I had selected, which turned
> > out to be SLOB (from testing the network swap stuff).
>
> krealloc() is in generic core code (mm/util.c) and is the same for all allocators.
Joy :/
> krealloc uses ksize() which is somewhat dicey for SLOB because it only works
> on kmalloc'ed memory. Is the krealloc used on memory allocated with kmalloc()?
> Slob's ksize could use a BUG_ON for the case in which ksize() is used on
> kmem_cache_alloc'd memory.
kernel/module.c: perpcu_modinit() reads:
pcpu_size = kmalloc(sizeof(pcpu_size[0]) * pcpu_num_allocated,
GFP_KERNEL);
kernel/module.c: split_block() reads:
new = krealloc(pcpu_size, sizeof(new[0])*pcpu_num_allocated*2,
GFP_KERNEL);
--
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/
Powered by blists - more mailing lists