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

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 17/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 17/08/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > On 13/08/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/