lkml.org 
[lkml]   [2009]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    SubjectRe: Q, slab, kmemleak_erase() and redzone?
    Date

    Pekka Enberg:
    > We are setting an element in the per CPU array to NULL so the the
    > kmemleak code in ____cache_alloc() is safe. Red-zoning is done at the
    > _object_ which is not touched by kmemleak. Looking at the oops, it
    > does seem likely that you have a bug in your module (or in some other
    > part of the kernel).

    Thanks for reply.
    In ____cache_alloc(), the variable 'ac' is assigned before
    cache_alloc_refill() call, and it is used for the parameter of
    kmemleak_erase(). The value may be changed by cache_alloc_refill(),
    isn't it?
    In this case, kmemleak_erase() receives the incorrect pointer and sets
    NULL to somewhere else which may be redzone?

    How about this fix?
    If cpu_cache_get() call is heavy and we cannot ignore it when KMEMLEAK
    is disabled, then a new wrapper may be necessary.

    diff --git a/mm/slab.c b/mm/slab.c
    index 71e0a1f..3f3e018 100644
    --- a/mm/slab.c
    +++ b/mm/slab.c
    @@ -3104,6 +3104,7 @@ static inline void *____cache_alloc(struct kmem_cache *cachep, gfp_t flags)
    } else {
    STATS_INC_ALLOCMISS(cachep);
    objp = cache_alloc_refill(cachep, flags);
    + ac = cpu_cache_get(cachep);
    }
    /*
    * To avoid a false negative, if an object that is in one of the


    J. R. Okajima


    \
     
     \ /
      Last update: 2009-11-24 08:09    [W:0.032 / U:0.024 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site