Re: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9

From: Catalin Marinas
Date: Thu Aug 17 2006 - 10:59:18 EST


On 17/08/06, Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx> wrote:
On 17/08/06, Catalin Marinas <catalin.marinas@xxxxxxxxx> wrote:
> On 13/08/06, Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx> wrote:
> > It's kmemleak 0.9 issue. I have tested kmemleak 0.8 on 2.6.18-rc1and
> > 2.6.18-rc2. I haven't seen this before.
>
> it looks like it was caused by commit
> fc818301a8a39fedd7f0a71f878f29130c72193d where free_block() now calls
> slab_destroy() with l3->list_lock held.

I'll revert this commit.

I'm not sure it's a good idea, it might have other implications in
slab.c. I better fix kmemleak (I think currently you could get a
deadlock only on SMP).

Please talk with Christoph Lameter, he is working on Modular Slab.
http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/0951.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0608.2/0030.html
Maybe he can help with this problem.

I haven't looked at these patches in detail but they look like making
the slab allocator cleaner.

Anyway, I still need to revisit the locking in kmemleak and not rely
on future changes to slab.c. At the moment I think I can avoid any
kmemleak locks when allocating memory (by using radix_tree_preload
with the radix trees). If this still fails, I'll think about writing
my own, very simple, memory allocator and avoid the re-entrance
problem.

Thanks.

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