linux-kernel - Re: [PATCH] mm/kmemleak: Do not skip stack frames

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20141021155821.GB17528@e104818-lin.cambridge.arm.com>
Date:	Tue, 21 Oct 2014 16:58:22 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/kmemleak: Do not skip stack frames

On Tue, Oct 21, 2014 at 01:19:29PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@...dia.com>
> 
> Trying to chase down memory leaks is much easier when the complete stack
> trace is available.
> 
> Signed-off-by: Thierry Reding <treding@...dia.com>
> ---
> It seems like this was initially set to 1 when merged in commit
> 3c7b4e6b8be4 (kmemleak: Add the base support) and later increased to 2
> in commit fd6789675ebf (kmemleak: Save the stack trace for early
> allocations). Perhaps there was a reason to skip the first few frames,
> but I've certainly found it difficult to find leaks when the stack trace
> doesn't point at the proper location.
> ---
>  mm/kmemleak.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 3cda50c1e394..55d9ad0f40d4 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -503,7 +503,7 @@ static int __save_stack_trace(unsigned long *trace)
>  	stack_trace.max_entries = MAX_TRACE;
>  	stack_trace.nr_entries = 0;
>  	stack_trace.entries = trace;
> -	stack_trace.skip = 2;
> +	stack_trace.skip = 0;

The reason for this was to avoid listing some of the kmemleak internals
(kmemleak_alloc -> create_object -> __save_stack_trace). I can see how
inlining of __save_stack_trace() would cause some of the last frames to
be missed. I would still prefer to keep it at 1 rather than 0?

Which architecture are you testing on? What's the additional trace you
get with this patch?

-- 
Catalin
--
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/