From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 6/6] powerpc/64s: Blacklist rtas entry/exit from kprobes
Date: Thu, 22 Jun 2017 22:22:44 +0530 [thread overview]
Message-ID: <20170622165244.l3i5fd5v6kpjuwlx@naverao1-tp.localdomain> (raw)
In-Reply-To: <20170622134858.63031e22@roar.ozlabs.ibm.com>
On 2017/06/22 01:48PM, Nicholas Piggin wrote:
> On Thu, 22 Jun 2017 00:08:42 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>
> > We can't take traps with relocation off, so blacklist enter_rtas() and
> > rtas_return_loc(). However, instead of blacklisting all of enter_rtas(),
> > introduce a new symbol __enter_rtas from where on we can't take a trap
> > and blacklist that.
> >
> > Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/kernel/entry_64.S | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> > index d376f07153d7..49c35450f399 100644
> > --- a/arch/powerpc/kernel/entry_64.S
> > +++ b/arch/powerpc/kernel/entry_64.S
> > @@ -1076,6 +1076,8 @@ _GLOBAL(enter_rtas)
> > rldicr r9,r9,MSR_SF_LG,(63-MSR_SF_LG)
> > ori r9,r9,MSR_IR|MSR_DR|MSR_FE0|MSR_FE1|MSR_FP|MSR_RI|MSR_LE
> > andc r6,r0,r9
> > +
> > +__enter_rtas:
> > sync /* disable interrupts so SRR0/1 */
> > mtmsrd r0 /* don't get trashed */
>
> Along the lines of the system call patch... For consistency, could we
> put the __enter_rtas right after mtmsrd? And I wonder if we shoul
Sure.
> come up with a common prefix or postfix naming convention for these
> such labels used to control probing?
We could, but I am not sure it will help much. On the other hand, such
symbols may make backtraces pretty distracting.
I'm just using '__' as a prefix to make it less distracting, though it
isn't all that great either. I'm clearly hopeless with names o_O
The other option is to just blacklist entire functions, but we will then
lose the ability to probe in many places where we may have wanted to.
>
> How do opal calls avoid tracing?
It doesn't yet. I'm still going through the initial few symbols and
identifying what needs blacklisting. Opal is further down.
Thanks,
Naveen
prev parent reply other threads:[~2017-06-22 16:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-21 18:38 [PATCH v3 0/6] powerpc: build out kprobes blacklist -- series 3 Naveen N. Rao
2017-06-21 18:38 ` [PATCH v3 1/6] powerpc64/elfv1: Validate function pointer address in the function descriptor Naveen N. Rao
2017-06-22 3:22 ` Nicholas Piggin
2017-06-22 10:59 ` Michael Ellerman
2017-06-22 13:06 ` Nicholas Piggin
2017-06-22 14:01 ` Naveen N. Rao
2017-06-21 18:38 ` [PATCH v3 2/6] powerpc/64s: Convert .L__replay_interrupt_return to a local label Naveen N. Rao
2017-06-22 3:23 ` Nicholas Piggin
2017-06-21 18:38 ` [PATCH v3 3/6] powerpc/64s: Blacklist system_call() and system_call_common() from kprobes Naveen N. Rao
2017-06-22 3:36 ` Nicholas Piggin
2017-06-22 11:07 ` Michael Ellerman
2017-06-22 13:08 ` Nicholas Piggin
2017-06-22 14:34 ` Naveen N. Rao
2017-06-21 18:38 ` [PATCH v3 4/6] powerpc/64s: Un-blacklist system_call() " Naveen N. Rao
2017-06-22 3:41 ` Nicholas Piggin
2017-06-22 11:14 ` Michael Ellerman
2017-06-22 13:14 ` Nicholas Piggin
2017-06-22 15:43 ` Naveen N. Rao
2017-06-21 18:38 ` [PATCH v3 5/6] powerpc/64s: Blacklist functions invoked on a trap Naveen N. Rao
2017-06-22 3:44 ` Nicholas Piggin
2017-06-22 11:12 ` Michael Ellerman
2017-06-21 18:38 ` [PATCH v3 6/6] powerpc/64s: Blacklist rtas entry/exit from kprobes Naveen N. Rao
2017-06-22 3:48 ` Nicholas Piggin
2017-06-22 16:52 ` Naveen N. Rao [this message]
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=20170622165244.l3i5fd5v6kpjuwlx@naverao1-tp.localdomain \
--to=naveen.n.rao@linux.vnet.ibm.com \
--cc=ananth@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhiramat@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.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.