On 17/08/06, Catalin Marinas <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
