Re: Leaks in trace reported by kmemleak

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

Hmm - ok I'll retest this one - meanwhile here is my observation from
your previous post

It looks like this remove leaks from  i915 & kvm
But on the other hand there are ~4 other leaks now reported from
various kernel parts.


>
>> 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.
>

I think that no drastic solutions would need to be deployed in my case.
I would propose something like this:

When you display/resolve  stacktrace  with  cat
/sys/kernel/debug/kmemleak - you could remember decoded stacktraces in
some given buffer - and so next time - you would not need to decode
this stacktrace - and when the module is removed the stacktrace could
be displayed properly.

It's already time costly to keep stacktrace (very noticeable in drm -
where there is permanently something being allocated and deallocated)

IMHO it wouldn't be too time consuming to resolve traces even right
after scan command - as only new objects would need to be decoded.

Obviously it would cost slightly more memory to keep this string
output somewhere - but I think my machine will not miss that much 0.5M
for this purpose.

Zdenek