linux-kernel - [PATCH] lockdep: fixup stacktrace wastage

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: <1248096665.15751.8816.camel@twins>
Date:	Mon, 20 Jul 2009 15:31:05 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Dave Jones <davej@...hat.com>,
	Joao Correia <joaomiguelcorreia@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	mingo <mingo@...e.hu>
Subject: [PATCH] lockdep: fixup stacktrace wastage

On Thu, 2009-07-09 at 11:10 +0200, Peter Zijlstra wrote:
> On Thu, 2009-07-09 at 10:06 +0100, Catalin Marinas wrote:
> > On Wed, 2009-07-08 at 20:36 +0200, Peter Zijlstra wrote:
> > > As a side node, I see that each and every trace ends with a -1 entry:
> > > 
> > > ...
> > > [ 1194.412158]    [<c01f7990>] do_mount+0x3c0/0x7c0
> > > [ 1194.412158]    [<c01f7e14>] sys_mount+0x84/0xb0
> > > [ 1194.412158]    [<c01221b1>] syscall_call+0x7/0xb
> > > [ 1194.412158]    [<ffffffff>] 0xffffffff
> > > 
> > > Which seems to come from:
> > > 
> > > void save_stack_trace(struct stack_trace *trace)
> > > {
> > >         dump_trace(current, NULL, NULL, 0, &save_stack_ops, trace);
> > >         if (trace->nr_entries < trace->max_entries)
> > >                 trace->entries[trace->nr_entries++] = ULONG_MAX;
> > > }
> > > EXPORT_SYMBOL_GPL(save_stack_trace);
> > > 
> > > commit 006e84ee3a54e393ec6bef2a9bc891dc5bde2843 seems involved,..
> > 
> > The reason for this is that if there are no more traces to show, it
> > inserts -1. In this case, it cannot trace beyond the system call. If the
> > stack trace is truncated because of the maximum number of trace entries
> > it can show, you won't get a -1.
> > 
> > Before the commit above, it was always inserting -1 even if the trace
> > was longer than the maximum number of entries.
> 
> Seems daft to me, I'll fix up lockdep to truncate that last entry,
> having a gazillion copies of -1 in the trace entries doesn't make sense.

Bugger, not all arches have that. I'll queue up the below, if it breaks
anything, I'll go around and fix up all arches to never emit this -1
crap.

---
Subject: lockdep: fixup stacktrace wastage
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Date: Mon Jul 20 15:27:04 CEST 2009

Some silly architectures emit trailing -1 entries on stacktraces, trim those
to save space.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
---
 kernel/lockdep.c |    6 ++++++
 1 file changed, 6 insertions(+)

Index: linux-2.6/kernel/lockdep.c
===================================================================
--- linux-2.6.orig/kernel/lockdep.c
+++ linux-2.6/kernel/lockdep.c
@@ -367,6 +367,12 @@ static int save_trace(struct stack_trace
 
 	save_stack_trace(trace);
 
+	/*
+	 * Some daft arches put -1 at the end to indicate its a full trace.
+	 */
+	if (trace->entries[trace->nr_entries-1] == ULONG_MAX)
+		trace->nr_entries--;
+
 	trace->max_entries = trace->nr_entries;
 
 	nr_stack_trace_entries += trace->nr_entries;

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