Re: Leaks in trace reported by kmemleak

[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 */

> BTW - it's kind of ugly - that module removal destroys stack trace -
> it would be nice to see some hook for module unload - to eventually
> create a permanent stack trace for this occasion??

Kmemleak only uses whatever stacktrace mechanism is available in the
kernel. Resolving the symbol names when objects are allocated would
slow it down and it takes up more space in the traces. I don't have a
proper solution.

-- 
Catalin