From: Ingo Molnar <mingo@elte.hu>
To: Soeren Sandmann <sandmann@daimi.au.dk>,
Arjan van de Ven <arjan@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Fr??d??ric Weisbecker <fweisbec@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] x86: Get bp from the IRQ regs instead of directly from the CPU
Date: Fri, 23 Oct 2009 12:50:47 +0200 [thread overview]
Message-ID: <20091023105047.GA10071@elte.hu> (raw)
In-Reply-To: <ye8ljj3mlj5.fsf@camel16.daimi.au.dk>
* Soeren Sandmann <sandmann@daimi.au.dk> wrote:
> Passing 0 for bp causes dump_trace() to get bp directly from the
> hardware register. This leads to the IRQ stack being included in the
> generated call chains, which means the stack looks something like
> this:
>
> [ ip ] [ IRQ stack ] [ rest of stack trace ]
>
> which is incorrect and confusing to user space.
>
> Getting bp from the IRQ regs instead makes the tracing start after the
> IRQ stack:
>
> [ ip ] [ rest of stack trace ]
>
> Signed-off-by: Søren Sandmann Pedersen <sandmann@redhat.com>
Indeed, nice catch!
> ---
> arch/x86/kernel/cpu/perf_event.c | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
> index b5801c3..39b1d0c 100644
> --- a/arch/x86/kernel/cpu/perf_event.c
> +++ b/arch/x86/kernel/cpu/perf_event.c
> @@ -2177,10 +2177,18 @@ static const struct stacktrace_ops backtrace_ops = {
> static void
> perf_callchain_kernel(struct pt_regs *regs, struct perf_callchain_entry *entry)
> {
> + unsigned long bp;
> +
> callchain_store(entry, PERF_CONTEXT_KERNEL);
> callchain_store(entry, regs->ip);
>
> - dump_trace(NULL, regs, NULL, 0, &backtrace_ops, entry);
> +#ifdef CONFIG_FRAME_POINTER
> + bp = regs->bp;
> +#else
> + bp = 0;
> +#endif
> +
> + dump_trace(NULL, regs, NULL, bp, &backtrace_ops, entry);
> }
Wouldnt it be better to push this logic into dump_trace() itself? That
way other ways of backtrace generation would be improved as well, not
just perf events call-chains.
Ingo
next prev parent reply other threads:[~2009-10-23 10:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ye8vdi7mluz.fsf@camel16.daimi.au.dk>
2009-10-22 16:34 ` [PATCH 2/2 -tip] perf: Don't generate events for the idle task when exclude_idle is set Soeren Sandmann
2009-10-22 16:38 ` [PATCH] x86: Get bp from the IRQ regs instead of directly from the CPU Soeren Sandmann
2009-10-23 10:50 ` Ingo Molnar [this message]
2009-10-29 12:46 ` Soeren Sandmann
2010-11-05 11:14 ` [PATCH 0/1] x86: Eliminate bp argument from the stack tracing routines Søren Sandmann Pedersen
2010-11-07 21:24 ` Frederic Weisbecker
2010-11-08 11:38 ` Soeren Sandmann
2010-11-18 15:32 ` Frederic Weisbecker
2010-11-05 11:14 ` [PATCH] " Søren Sandmann Pedersen
2009-10-23 7:35 ` [PATCH 1/2 -tip] perf: Keep track of remaining time when enabling/disabling swevent hrtimers Ingo Molnar
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=20091023105047.GA10071@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=sandmann@daimi.au.dk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox