[lkml]   [2006]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9
    On 17/08/06, Catalin Marinas <> 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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-29 23:09    [W:0.037 / U:4.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site