diff options
author | Frederic Weisbecker <fweisbec@gmail.com> | 2010-03-03 02:25:22 +0100 |
---|---|---|
committer | Frederic Weisbecker <fweisbec@gmail.com> | 2010-03-03 04:07:23 +0100 |
commit | 29044ad1509ecc229f1d5a31aeed7a8dc61a71c4 (patch) | |
tree | 3a489d6d870c99f89892a7075436901dd723343d /arch/x86/Makefile_32.cpu | |
parent | 1e259e0a9982078896f3404240096cbea01daca4 (diff) | |
download | talos-obmc-linux-29044ad1509ecc229f1d5a31aeed7a8dc61a71c4.tar.gz talos-obmc-linux-29044ad1509ecc229f1d5a31aeed7a8dc61a71c4.zip |
x86/stacktrace: Don't dereference bad frame pointers
Callers of a stacktrace might pass bad frame pointers. Those
are usually checked for safety in stack walking helpers before
any dereferencing, but this is not the case when we need to go
through one more frame pointer that backlinks the irq stack to
the previous one, as we don't have any reliable address boudaries
to compare this frame pointer against.
This raises crashes when we record callchains for ftrace events
with perf because we don't use the right helpers to capture
registers there. We get wrong frame pointers as we call
task_pt_regs() even on kernel threads, which is a wrong thing
as it gives us the initial state of any kernel threads freshly
created. This is even not what we want for user tasks. What we want
is a hot snapshot of registers when the ftrace event triggers, not
the state before a task entered the kernel.
This requires more thoughts to do it correctly though.
So first put a guardian to ensure the given frame pointer
can be dereferenced to avoid crashes. We'll think about how to fix
the callers in a subsequent patch.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: 2.6.33.x <stable@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Diffstat (limited to 'arch/x86/Makefile_32.cpu')
0 files changed, 0 insertions, 0 deletions