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

[Catalin Marinas]

On 17/08/06, Catalin Marinas <catalin.marinas@xxxxxxxxx> wrote:
> it looks like it was caused by commit
> fc818301a8a39fedd7f0a71f878f29130c72193d where free_block() now calls
> slab_destroy() with l3->list_lock held.
[...]
> It leaves me with the options of either implementing my own memory
> allocator based on pages (including a simple hash table instead of
> radix tree) or fix the locking in kmemleak so that memory allocations
> happen without memleak_lock held. The latter is a bit complicated as
> well since any slab allocation causes a re-entrance into kmemleak.

FYI, I couldn't fix the locking dependency issues without modifying
the radix-tree implementation since even if you preload the tree
outside the memleak lock, it still tries to allocate memory in
radix_tree_insert.

I'll instead use a hash table (together with hlist) where I can
control the memory allocations and make more use of RCU. In my few
initial tests, the memory search with hash tables is about the same
speed (if not slightly faster) as the radix-tree implementation.

I will post a new kmemleak version by the end of this week.

--
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/