[lkml]   [2009]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Leaks in trace reported by kmemleak
    2009/10/16 Zdenek Kabelac <>:
    > 2009/10/16 Catalin Marinas <>:
    >> Zdenek Kabelac <> wrote:
    >>> Yes -same - though I forget to mention that log contained these two
    >>> extra messages:
    >>> (got lost in other debug stuff :( )...
    >>> So it could be the parameters in your first patch were not correct ?
    >>> [drm] Initialized drm 1.1.0 20060810
    >>> kmemleak: Scan area larger than object 0xffffffffa033b000
    >> Ah, I forgot that kmemleak_scan_area takes an offset inside an object
    >> rather than an absolute address. Something like below (I should
    >> actually change this prototype of this function, it doesn't need to be
    >> so complex):
    >> diff --git a/kernel/module.c b/kernel/module.c
    >> index 8b7d880..8cc4406 100644
    >> --- a/kernel/module.c
    >> +++ b/kernel/module.c
    >> @@ -2383,6 +2383,10 @@ static noinline struct module *load_module(void __user *umod,
    >>                                         "_ftrace_events",
    >>                                         sizeof(*mod->trace_events),
    >>                                         &mod->num_trace_events);
    >> +       kmemleak_scan_area(mod->module_core, (unsigned long)mod->trace_events -
    >> +                          (unsigned long)mod->module_core,
    >> +                          sizeof(*mod->trace_events) * mod->num_trace_events,
    >> +                          GFP_KERNEL);
    >>  #endif
    >>        /* sechdrs[0].sh_size is always zero */

    So I've tested this modified version and it gives much better result
    with respect to amount of leaked objects
    It gets even to 0 - so even dma is not usually printed now - thus I
    think the dma_debug_init is not a real issue.
    As on some scan they are present and on some they are not there.

    And also traces' strdup leaks are now gone for i915 and kvm.

    But it's still not perfect - as my machine now has a lot of these
    entries in the boot log:
    (I'm using only this patch - and not the next one where you removed
    call to kmemleak_load_module)

    kmemleak: Scan area larger than object 0xffffffffa04f0000
    Pid: 1752, comm: modprobe Not tainted 2.6.32-rc5-00002-gdab7e9a #27
    Call Trace:
    [<ffffffff8140ee6f>] kmemleak_scan_area+0x15f/0x1a0
    [<ffffffff810a0089>] load_module+0xff9/0x1af0
    [<ffffffff8109ca70>] ? setup_modinfo_srcversion+0x0/0x30
    [<ffffffff810a0bfb>] sys_init_module+0x7b/0x260
    [<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
    kmemleak: Object 0xffffffffa04f0000 (size 8192):
    kmemleak: comm "modprobe", pid 1752, jiffies 4294886643
    kmemleak: min_count = 0
    kmemleak: count = -1
    kmemleak: flags = 0x9
    kmemleak: backtrace:
    [<ffffffff8140eaf6>] kmemleak_alloc+0x26/0x60
    [<ffffffff8111993a>] __vmalloc_area+0x4a/0x60
    [<ffffffff8102b6ee>] module_alloc+0x5e/0x60
    [<ffffffff8109c626>] module_alloc_update_bounds+0x16/0x50
    [<ffffffff8109f8d3>] load_module+0x843/0x1af0
    [<ffffffff810a0bfb>] sys_init_module+0x7b/0x260
    [<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
    [<ffffffffffffffff>] 0xffffffffffffffff

    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: 2009-10-16 17:13    [W:0.048 / U:12.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site