lkml.org 
[lkml]   [2006]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9
    On 15/08/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
    > On 14/08/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
    > > The kmemleak+slab locking is a bit complicated because memleak itself
    > > needs to allocate memory and avoid recursive calls to it (the
    > > pointer_cache and the radix_tree allocations). The kmemleak-related
    > > allocations are not tracked by kmemleak.
    > >
    > > I see the following solutions:
    > >
    > > 1. acquire the memleak_lock at the beginning of an alloc/free function
    > > and release it when finished while allowing recursive/nested calls
    > > (and only call the memleak_* functions during the outermost lock).
    > > This would mean ignoring the off-slab management allocations as these
    > > would lead to deadlock because of the recursive call into kmemleak.
    > > This locking should be placed around cache_reap() as well (actually,
    > > around all the entry points in the mm/slab.c file).
    >
    > This would actually work because the slab allocation functions may sleep.

    I meant "would *not*" above.

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

    \
     
     \ /
      Last update: 2006-08-15 17:29    [W:0.019 / U:20.516 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site