From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H . Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Paul Mackerras <paulus@samba.org>,
Steven Rostedt <rostedt@goodmis.org>,
"2 . 6 . 33 . x" <stable@kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: [GIT PULL]
Date: Wed, 3 Mar 2010 04:09:02 +0100 [thread overview]
Message-ID: <1267585742-3853-1-git-send-regression-fweisbec@gmail.com> (raw)
Ingo,
Please pull the perf/urgent branch that can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
perf/urgent
Thanks,
Frederic
---
Frederic Weisbecker (1):
x86/stacktrace: Don't dereference bad frame pointers
arch/x86/kernel/dumpstack_64.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
---
commit 29044ad1509ecc229f1d5a31aeed7a8dc61a71c4
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date: Wed Mar 3 02:25:22 2010 +0100
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>
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index 0ad9597..a6c906c 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -125,9 +125,15 @@ fixup_bp_irq_link(unsigned long bp, unsigned long *stack,
{
#ifdef CONFIG_FRAME_POINTER
struct stack_frame *frame = (struct stack_frame *)bp;
+ unsigned long next;
- if (!in_irq_stack(stack, irq_stack, irq_stack_end))
- return (unsigned long)frame->next_frame;
+ if (!in_irq_stack(stack, irq_stack, irq_stack_end)) {
+ if (!probe_kernel_address(&frame->next_frame, next))
+ return next;
+ else
+ WARN_ONCE(1, "Perf: bad frame pointer = %p in "
+ "callchain\n", &frame->next_frame);
+ }
#endif
return bp;
}
next reply other threads:[~2010-03-03 3:09 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-03 3:09 Frederic Weisbecker [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-08-09 13:27 [GIT PULL] David Howells
2022-08-09 17:29 ` pr-tracker-bot
2022-06-03 19:20 Eric W. Biederman
2022-06-03 23:25 ` pr-tracker-bot
2021-12-23 19:55 Eric W. Biederman
2021-12-23 19:55 ` Eric W. Biederman
2019-02-11 20:48 Kevin Hilman
2019-02-11 20:48 ` Kevin Hilman
2019-02-11 20:56 ` Kevin Hilman
2019-02-11 20:56 ` Kevin Hilman
2018-05-08 13:38 Frederic Weisbecker
2016-04-12 18:34 David Howells
2015-07-15 11:51 Tero Kristo
2015-07-15 21:05 ` Stephen Boyd
2012-06-18 20:48 Roland Stigge
2012-06-30 23:29 ` Olof Johansson
2012-07-01 15:40 ` Roland Stigge
2012-07-02 16:25 ` Olof Johansson
2012-04-10 19:05 Stephen Warren
2012-04-10 21:29 ` Mark Brown
2012-03-13 4:56 [git pull] Jesse Barnes
2011-12-19 11:29 [GIT PULL] Sascha Hauer
2011-12-20 5:33 ` Olof Johansson
2011-02-11 13:40 Ted Ts'o
2011-02-12 0:33 ` Linus Torvalds
2011-02-12 0:33 ` Linus Torvalds
2011-02-12 1:41 ` Eric Sandeen
2011-02-12 1:41 ` Eric Sandeen
2011-02-12 13:28 ` Ted Ts'o
2010-09-10 12:52 Nicolas Ferre
2010-09-10 12:52 ` Nicolas Ferre
2010-09-10 13:16 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-10 13:16 ` Jean-Christophe PLAGNIOL-VILLARD
2007-10-23 9:43 Haavard Skinnemoen
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=1267585742-3853-1-git-send-regression-fweisbec@gmail.com \
--to=fweisbec@gmail.com \
--cc=acme@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=stable@kernel.org \
--cc=tglx@linutronix.de \
/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.