From: Thierry Reding <[email protected]>

Trying to chase down memory leaks is much easier when the complete stack
trace is available.

Signed-off-by: Thierry Reding <[email protected]>
---
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;
        save_stack_trace(&stack_trace);
 
        return stack_trace.nr_entries;
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to