From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Frederic Weisbecker <fweisbec@gmail.com>,
"H. Peter Anvin" <hpa@zytor.com>,
yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH 4/5] ftrace/x86: Have arch x86_64 use breakpoints instead of stop machine
Date: Thu, 26 Apr 2012 19:43:46 +0900 [thread overview]
Message-ID: <4F9926E2.4010100@hitachi.com> (raw)
In-Reply-To: <20120425184930.873468066@goodmis.org>
(2012/04/26 3:48), Steven Rostedt wrote:
> From: Steven Rostedt <srostedt@redhat.com>
>
> This method changes x86 to add a breakpoint to the mcount locations
> instead of calling stop machine.
>
> Now that iret can be handled by NMIs, we perform the following to
> update code:
>
> 1) Add a breakpoint to all locations that will be modified
>
> 2) Sync all cores
>
> 3) Update all locations to be either a nop or call (except breakpoint
> op)
>
> 4) Sync all cores
>
> 5) Remove the breakpoint with the new code.
>
> 6) Sync all cores
>
> [
> Added updates that Masami suggested:
> Use unlikely(modifying_ftrace_code) in int3 trap to keep kprobes efficient.
> Don't use NOTIFY_* in ftrace handler in int3 as it is not a notifier.
> ]
I just have a few comments :)
[...]
> +int modifying_ftrace_code __read_mostly;
> +
> +/*
> + * A breakpoint was added to the code address we are about to
> + * modify, and this is the handle that will just skip over it.
> + * We are either changing a nop into a trace call, or a trace
> + * call to a nop. While the change is taking place, we treat
> + * it just like it was a nop.
> + */
> +int ftrace_int3_handler(int cmd, const char *str,
> + struct pt_regs *regs, long err, int trap, int sig)
> +{
> + if (!modifying_ftrace_code || cmd != DIE_INT3 || !regs)
> + return 0;
> +
At this moment, all of these checks are meaningless, because
this is not a handler but just a fixup code in int3 isr. :)
So, I think you can just define "int ftrace_int3_fixup(regs)"
for this purpose.
> + if (!ftrace_location(regs->ip - 1))
> + return 0;
> +
> + regs->ip += MCOUNT_INSN_SIZE - 1;
> +
> + return 1;
> +}
[...]
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index ff9281f1..1712485 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -50,6 +50,7 @@
> #include <asm/processor.h>
> #include <asm/debugreg.h>
> #include <linux/atomic.h>
> +#include <asm/ftrace.h>
> #include <asm/traps.h>
> #include <asm/desc.h>
> #include <asm/i387.h>
> @@ -303,8 +304,14 @@ gp_in_kernel:
> }
>
> /* May run on IST stack. */
> -dotraplinkage void __kprobes do_int3(struct pt_regs *regs, long error_code)
> +dotraplinkage void __kprobes notrace do_int3(struct pt_regs *regs, long error_code)
> {
> +#ifdef CONFIG_FUNCTION_TRACER
I guess CONFIG_DYNAMIC_FTRACE ?
> + /* ftrace must be first, everything else may cause a recursive crash */
> + if (unlikely(modifying_ftrace_code) &&
> + ftrace_int3_handler(DIE_INT3, "int3", regs, error_code, 3, SIGTRAP))
> + return;
> +#endif
Thank you!
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2012-04-26 10:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-25 18:48 [PATCH 0/5] [GIT PULL] tracing: updates for 3.5 Steven Rostedt
2012-04-25 18:48 ` [PATCH 1/5] tracing: Add percpu buffers for trace_printk() Steven Rostedt
2012-04-25 18:48 ` [PATCH 2/5] tracing: Remove an unneeded check in trace_seq_buffer() Steven Rostedt
2012-04-25 18:48 ` [PATCH 3/5] ring-buffer: Add per_cpu ring buffer control files Steven Rostedt
2012-04-25 18:48 ` [PATCH 4/5] ftrace/x86: Have arch x86_64 use breakpoints instead of stop machine Steven Rostedt
2012-04-26 10:43 ` Masami Hiramatsu [this message]
2012-04-26 12:13 ` Steven Rostedt
2012-04-25 18:48 ` [PATCH 5/5] ftrace/x86: Remove the complex ftrace NMI handling code Steven Rostedt
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=4F9926E2.4010100@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=yrl.pp-manager.tt@hitachi.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.