From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Masami Hiramatsu <mhiramat@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 4/7] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel
Date: Thu, 27 Jun 2019 20:20:56 +0530 [thread overview]
Message-ID: <1561646984.1q83gyp5m8.naveen@linux.ibm.com> (raw)
In-Reply-To: <841386feda429a1f0d4b7442c3ede1ed91466f92.1561634177.git.naveen.n.rao@linux.v net.ibm.com>
Naveen N. Rao wrote:
> With -mprofile-kernel, gcc emits 'mflr r0', followed by 'bl _mcount' to
> enable function tracing and profiling. So far, with dynamic ftrace, we
> used to only patch out the branch to _mcount(). However, mflr is
> executed by the branch unit that can only execute one per cycle on
> POWER9 and shared with branches, so it would be nice to avoid it where
> possible.
>
> We cannot simply nop out the mflr either. When enabling function
> tracing, there can be a race if tracing is enabled when some thread was
> interrupted after executing a nop'ed out mflr. In this case, the thread
> would execute the now-patched-in branch to _mcount() without having
> executed the preceding mflr.
>
> To solve this, we now enable function tracing in 2 steps: patch in the
> mflr instruction, use 'smp_call_function(isync);
> synchronize_rcu_tasks()' to ensure all existing threads make progress,
> and then patch in the branch to _mcount(). We override
> ftrace_replace_code() with a powerpc64 variant for this purpose.
>
> Suggested-by: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/trace/ftrace.c | 258 ++++++++++++++++++++++++++---
> 1 file changed, 236 insertions(+), 22 deletions(-)
>
I missed adding a comment here to explain the changes. As discussed in
the previous series, I think we are ok with this patch from a CMODX
perspective. For smp_call_function(), I decided to have it included in
this patch since we know that we need it here for sure. I am not
entirely sure we want to do that in patch_instruction() since ftrace
doesn't seem to need it elsewhere. As Nick Piggin pointed out, we may
want to have users of patch_instruction() (kprobes) add the necessary
synchronization.
Thanks,
Naveen
next prev parent reply other threads:[~2019-06-27 14:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 11:23 [PATCH v2 0/7] powerpc/ftrace: Patch out -mprofile-kernel instructions Naveen N. Rao
2019-06-27 11:23 ` [PATCH v2 1/7] ftrace: Expose flags used for ftrace_replace_code() Naveen N. Rao
2022-02-23 12:13 ` Christophe Leroy
2022-03-02 16:54 ` Naveen N. Rao
2019-06-27 11:23 ` [PATCH v2 2/7] x86/ftrace: Fix use of flags in ftrace_replace_code() Naveen N. Rao
[not found] ` <abc56ad177f370ec423edcfc538d35b418c1808e.1561634177.git.naveen.n.rao@linux.v net.ibm.com>
2019-06-27 11:27 ` Naveen N. Rao
2019-06-27 13:29 ` Steven Rostedt
2019-06-27 14:49 ` Naveen N. Rao
2019-06-27 11:23 ` [PATCH v2 3/7] ftrace: Expose __ftrace_replace_code() Naveen N. Rao
2019-06-27 14:36 ` Steven Rostedt
2019-06-27 11:23 ` [PATCH v2 4/7] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel Naveen N. Rao
[not found] ` <841386feda429a1f0d4b7442c3ede1ed91466f92.1561634177.git.naveen.n.rao@linux.v net.ibm.com>
2019-06-27 14:50 ` Naveen N. Rao [this message]
2019-06-27 15:08 ` Steven Rostedt
2019-06-27 15:28 ` Naveen N. Rao
2019-06-27 16:13 ` Steven Rostedt
2019-07-01 8:51 ` Naveen N. Rao
2019-06-28 7:01 ` Nicholas Piggin
2019-06-27 11:23 ` [PATCH v2 5/7] ftrace: Update ftrace_location() for powerpc -mprofile-kernel Naveen N. Rao
2019-06-27 11:23 ` [PATCH v2 6/7] kprobes/ftrace: Use ftrace_location() when [dis]arming probes Naveen N. Rao
2019-06-27 11:23 ` [PATCH v2 7/7] powerpc/kprobes: Allow probing on any ftrace address Naveen N. Rao
2019-06-27 14:19 ` Masami Hiramatsu
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=1561646984.1q83gyp5m8.naveen@linux.ibm.com \
--to=naveen.n.rao@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=rostedt@goodmis.org \
/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