All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.