lkml.org 
[lkml]   [2009]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Leaks in trace reported by kmemleak
    From
    2009/10/15 Catalin Marinas <catalin.marinas@arm.com>:
    > On Thu, 2009-10-15 at 17:46 +0800, Li Zefan wrote:
    >> Zdenek Kabelac wrote:
    >> > I've noticed your latest patch for memory leak in filter setting
    >> > (8ad807318fcd...) - but even with this patch - kmemleak seems to still
    >> > report  lots  (~900) of following leaks - note - they come only from
    >> > i915 and kvm module - so I'm not sure if these two modules are doing
    >> > something wrong or the problem is in trace code.
    >> >
    >> > It looks like whole directory is somehow forgotten.
    >> >
    >>
    >> Fortunately those are false-positives:
    >>
    >>  # modprobe i915
    >>  # echo scan > /debug/kmemleak
    >>  # cat /debug/kmemleak
    >>  (lots of "leaks")
    >>  # rmmod i915
    >>  # echo scan > /debug/kmemleak
    >>  # cat /debug/kmemleak
    >>  (no leaks)
    >>
    >> All the memory allocated when loading the module is
    >> freed in trace_module_remove_events() at module unload.
    >>
    >> But I haven't looked into how to suppress those false-postives.
    >> I'd like to, but I'm going to leave my office and won't be
    >> back until 26th..
    >
    > It is probably caused by the fact that kmemleak doesn't scan the
    > mod->trace_events data in a module (the _ftrace_events section). It only
    > scans those sections beginning with .data and .bss in a module. Maybe we
    > should add "_ftrace_events" as well or just prefix it with ".data".
    >
    > Something like below may fix this (untested):
    >
    > diff --git a/kernel/module.c b/kernel/module.c
    > index 8b7d880..1449691 100644
    > --- a/kernel/module.c
    > +++ b/kernel/module.c
    > @@ -2383,6 +2383,9 @@ 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, mod->trace_events,
    > +                          sizeof(*mod->trace_events) * mod->num_trace_events,
    > +                          GFP_KERNEL);
    >  #endif
    >  #ifdef CONFIG_FTRACE_MCOUNT_RECORD
    >        /* sechdrs[0].sh_size is always zero */
    >
    >

    Yep - I've assume it could be also a problem of missing memory segment
    in kmemleak scanning routine - but it was weird that just these two
    modules (i915 & kvm) are doing such strange thing.

    I've tested patch above with added cast ( (unsigned
    long)mod->trace_events) to pacify warning - but it did not helped -
    leaks are still printed.

    And I add another leak - which might be from the same range of problem :
    (it's also present many times - and it even looks like hex dump is
    changing so it's probably even frequently used memory region - at
    least in few such objects)

    unreferenced object 0xffff88013aa4ad80 (size 192):
    comm "swapper", pid 1, jiffies 4294877809
    hex dump (first 32 bytes):
    c0 dc a4 3a 01 88 ff ff 00 0c 79 39 01 88 ff ff ...:......y9....
    90 00 cf 3a 01 88 ff ff 02 00 00 00 00 00 00 00 ...:............
    backtrace:
    [<ffffffff8140e9a6>] kmemleak_alloc+0x26/0x60
    [<ffffffff81126a01>] kmem_cache_alloc_notrace+0xc1/0x140
    [<ffffffff8127256a>] dma_debug_init+0x23a/0x3a0
    [<ffffffff81864a37>] pci_iommu_init+0xe/0x28
    [<ffffffff8100904c>] do_one_initcall+0x3c/0x1d0
    [<ffffffff8185f4e6>] kernel_init+0x150/0x1a6
    [<ffffffff8100d21a>] child_rip+0xa/0x20
    [<ffffffffffffffff>] 0xffffffffffffffff


    Zdenek
    --
    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: 2009-10-16 09:49    [W:0.027 / U:30.524 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site