From: Frederic Weisbecker <fweisbec@gmail.com>
To: Luca Barbieri <luca@luca-barbieri.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: perf record -g hangs the system
Date: Thu, 21 Jan 2010 12:18:52 +0100 [thread overview]
Message-ID: <20100121111850.GD5017@nowhere> (raw)
In-Reply-To: <ff13bc9a1001210310x5ebc9993kbf6b302285d2d9a4@mail.gmail.com>
On Thu, Jan 21, 2010 at 12:10:12PM +0100, Luca Barbieri wrote:
> I'm experiencing a system lockup running the following command:
> perf record -g true
>
> The system hangs and does not respond to any sysrq.
> No messages are printed to netconsole.
>
> This is with 2.6.33-rc4 on an x86-32 Core 2 dual core machine.
>
> Any tips on how to debug/fix this?
It should be fixed in latest linus's git tree with the
following patch:
commit c2c5d45d46c8c0fd34291dec958670ad4816796f
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date: Thu Dec 31 03:52:25 2009 +0100
perf: Stop stack frame walking off kernel addresses boundaries
While processing kernel perf callchains, an bad entry can be
considered as a valid stack pointer but not as a kernel address.
In this case, we hang in an endless loop. This can happen in an
x86-32 kernel after processing the last entry in a kernel
stacktrace.
Just stop the stack frame walking after we encounter an invalid
kernel address.
This fixes a hard lockup in x86-32.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1262227945-27014-1-git-send-regression-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index c56bc28..6d81755 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -123,13 +123,15 @@ print_context_stack_bp(struct thread_info *tinfo,
while (valid_stack_ptr(tinfo, ret_addr, sizeof(*ret_addr), end)) {
unsigned long addr = *ret_addr;
- if (__kernel_text_address(addr)) {
- ops->address(data, addr, 1);
- frame = frame->next_frame;
- ret_addr = &frame->return_address;
- print_ftrace_graph_addr(addr, data, ops, tinfo, graph);
- }
+ if (!__kernel_text_address(addr))
+ break;
+
+ ops->address(data, addr, 1);
+ frame = frame->next_frame;
+ ret_addr = &frame->return_address;
+ print_ftrace_graph_addr(addr, data, ops, tinfo, graph);
}
+
return (unsigned long)frame;
}
EXPORT_SYMBOL_GPL(print_context_stack_bp);
next prev parent reply other threads:[~2010-01-21 11:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 11:10 perf record -g hangs the system Luca Barbieri
2010-01-21 11:18 ` Frederic Weisbecker [this message]
2010-01-21 12:19 ` Luca Barbieri
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=20100121111850.GD5017@nowhere \
--to=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luca@luca-barbieri.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.