[lkml]   [2012]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    Subject[15/15] slub: fix a possible memleak in __slab_alloc()
    3.0-stable review patch.  If anyone has any objections, please let me know.


    From: Eric Dumazet <>

    commit 73736e0387ba0e6d2b703407b4d26168d31516a7 upstream.

    Zhihua Che reported a possible memleak in slub allocator on
    CONFIG_PREEMPT=y builds.

    It is possible current thread migrates right before disabling irqs in
    __slab_alloc(). We must check again c->freelist, and perform a normal
    allocation instead of scratching c->freelist.

    Many thanks to Zhihua Che for spotting this bug, introduced in 2.6.39

    V2: Its also possible an IRQ freed one (or several) object(s) and
    populated c->freelist, so its not a CONFIG_PREEMPT only problem.

    Reported-by: Zhihua Che <>
    Signed-off-by: Eric Dumazet <>
    Acked-by: Christoph Lameter <>
    Signed-off-by: Pekka Enberg <>
    Signed-off-by: Greg Kroah-Hartman <>

    mm/slub.c | 6 ++++++
    1 file changed, 6 insertions(+)

    --- a/mm/slub.c
    +++ b/mm/slub.c
    @@ -1818,6 +1818,11 @@ static void *__slab_alloc(struct kmem_ca
    if (unlikely(!node_match(c, node)))
    goto another_slab;

    + /* must check again c->freelist in case of cpu migration or IRQ */
    + object = c->freelist;
    + if (object)
    + goto update_freelist;
    stat(s, ALLOC_REFILL);

    @@ -1827,6 +1832,7 @@ load_freelist:
    if (kmem_cache_debug(s))
    goto debug;

    c->freelist = get_freepointer(s, object);
    page->inuse = page->objects;
    page->freelist = NULL;

     \ /
      Last update: 2012-02-17 02:11    [W:0.047 / U:29.580 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site