lkml.org 
[lkml]   [2009]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: Leaks in trace reported by kmemleak
    From
    Date
    On Fri, 2009-10-16 at 09:45 +0200, Zdenek Kabelac wrote:
    > 2009/10/15 Catalin Marinas <catalin.marinas@arm.com>:
    > >> 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 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.

    Same trace-related leaks?

    Do any of the leaks disappear with subsequent memory scans (echo scan >
    debug/kmemleak)?

    Could you try the patch below? It ensures that all the module memory is
    scanned:

    diff --git a/kernel/module.c b/kernel/module.c
    index 8b7d880..fc6ef3a 100644
    --- a/kernel/module.c
    +++ b/kernel/module.c
    @@ -2036,36 +2036,6 @@ static void *module_alloc_update_bounds(unsigned long size)
    return ret;
    }

    -#ifdef CONFIG_DEBUG_KMEMLEAK
    -static void kmemleak_load_module(struct module *mod, Elf_Ehdr *hdr,
    - Elf_Shdr *sechdrs, char *secstrings)
    -{
    - unsigned int i;
    -
    - /* only scan the sections containing data */
    - kmemleak_scan_area(mod->module_core, (unsigned long)mod -
    - (unsigned long)mod->module_core,
    - sizeof(struct module), GFP_KERNEL);
    -
    - for (i = 1; i < hdr->e_shnum; i++) {
    - if (!(sechdrs[i].sh_flags & SHF_ALLOC))
    - continue;
    - if (strncmp(secstrings + sechdrs[i].sh_name, ".data", 5) != 0
    - && strncmp(secstrings + sechdrs[i].sh_name, ".bss", 4) != 0)
    - continue;
    -
    - kmemleak_scan_area(mod->module_core, sechdrs[i].sh_addr -
    - (unsigned long)mod->module_core,
    - sechdrs[i].sh_size, GFP_KERNEL);
    - }
    -}
    -#else
    -static inline void kmemleak_load_module(struct module *mod, Elf_Ehdr *hdr,
    - Elf_Shdr *sechdrs, char *secstrings)
    -{
    -}
    -#endif
    -
    /* Allocate and load the module: note that size of section 0 is always
    zero, and we rely on this for optional sections. */
    static noinline struct module *load_module(void __user *umod,
    @@ -2293,7 +2263,6 @@ static noinline struct module *load_module(void __user *umod,
    }
    /* Module has been moved. */
    mod = (void *)sechdrs[modindex].sh_addr;
    - kmemleak_load_module(mod, hdr, sechdrs, secstrings);

    #if defined(CONFIG_MODULE_UNLOAD) && defined(CONFIG_SMP)
    mod->refptr = percpu_modalloc(sizeof(local_t), __alignof__(local_t),
    > 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

    Same as above, does it disappear with subsequent scans? This doesn't
    look immediately like a false positive, it needs a bit more
    investigation.

    Thanks.

    --
    Catalin



    \
     
     \ /
      Last update: 2009-10-16 13:07    [W:0.026 / U:31.988 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site