lkml.org 
[lkml]   [2009]   [Oct]   [15]   [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 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



\
 
 \ /
  Last update: 2009-10-15 13:27    [W:0.075 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site