linux-kernel - Re: Leaks in trace reported by kmemleak

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c4e36d110910160728n5ceefaa8u6b9989aec0564628@mail.gmail.com>
Date:	Fri, 16 Oct 2009 16:28:47 +0200
From:	Zdenek Kabelac <zdenek.kabelac@...il.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Li Zefan <lizf@...fujitsu.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: Leaks in trace reported by kmemleak

2009/10/16 Catalin Marinas <catalin.marinas@....com>:
> Zdenek Kabelac <zdenek.kabelac@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/