Messages in this thread Patch in this message | | | Subject | Re: Leaks in trace reported by kmemleak | From | Catalin Marinas <> | Date | Thu, 15 Oct 2009 12:22:58 +0100 |
| |
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 */
-- Catalin
| |