From: Peter Zijlstra <peterz@infradead.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Dave Jones" <davej@redhat.com>,
"Joao Correia" <joaomiguelcorreia@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
"Américo Wang" <xiyou.wangcong@gmail.com>,
"Frederic Weisbecker" <fweisbec@gmail.com>,
"Arjan van de Ven" <arjan@linux.intel.com>, mingo <mingo@elte.hu>
Subject: [PATCH] lockdep: fixup stacktrace wastage
Date: Mon, 20 Jul 2009 15:31:05 +0200 [thread overview]
Message-ID: <1248096665.15751.8816.camel@twins> (raw)
In-Reply-To: <1247130598.9777.326.camel@twins>
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@chello.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@chello.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;
next prev parent reply other threads:[~2009-07-20 13:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 15:25 [PATCH 1/3] Increase lockdep limits: MAX_STACK_TRACE_ENTRIES Joao Correia
2009-07-07 15:33 ` Peter Zijlstra
[not found] ` <a5d9929e0907070838q7ed3306du3bb7880e47d7207b@mail.gmail.com>
2009-07-07 15:38 ` Fwd: " Joao Correia
[not found] ` <1246981444.9777.11.camel@twins>
2009-07-07 15:50 ` Joao Correia
2009-07-07 15:55 ` Peter Zijlstra
2009-07-07 15:59 ` Joao Correia
2009-07-08 17:22 ` Dave Jones
2009-07-08 18:36 ` Peter Zijlstra
2009-07-08 18:44 ` Dave Jones
2009-07-08 19:48 ` Joao Correia
2009-07-08 19:56 ` Peter Zijlstra
2009-07-09 4:39 ` Dave Jones
2009-07-09 8:02 ` Peter Zijlstra
2009-07-09 16:10 ` Dave Jones
2009-07-09 17:07 ` Peter Zijlstra
2009-07-10 15:50 ` Joao Correia
2009-07-09 9:06 ` Catalin Marinas
2009-07-09 9:09 ` Peter Zijlstra
2009-07-20 13:31 ` Peter Zijlstra [this message]
2009-08-02 13:14 ` [tip:core/locking] lockdep: Fix backtraces tip-bot for Peter Zijlstra
2009-08-02 13:51 ` tip-bot for Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1248096665.15751.8816.camel@twins \
--to=peterz@infradead.org \
--cc=arjan@linux.intel.com \
--cc=catalin.marinas@arm.com \
--cc=davej@redhat.com \
--cc=fweisbec@gmail.com \
--cc=joaomiguelcorreia@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox