Messages in this thread | | | Date | Fri, 16 Oct 2009 17:07:59 +0200 | Subject | Re: Leaks in trace reported by kmemleak | From | Zdenek Kabelac <> |
| |
2009/10/16 Zdenek Kabelac <zdenek.kabelac@gmail.com>: > 2009/10/16 Catalin Marinas <catalin.marinas@arm.com>: >> Zdenek Kabelac <zdenek.kabelac@gmail.com> 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 >> #ifdef CONFIG_FTRACE_MCOUNT_RECORD >> /* 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
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/
| |