linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Anton Blanchard <anton@samba.org>,
	linuxppc-dev@lists.ozlabs.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: Re: [RFC PATCH 2/4] powerpc: kprobe: add arch specific blacklist
Date: Fri, 18 Nov 2016 16:04:27 +0900	[thread overview]
Message-ID: <20161118160427.c1fa43473cd96e0bcc3b35a6@kernel.org> (raw)
In-Reply-To: <87y40hgwz2.fsf@concordia.ellerman.id.au>

On Fri, 18 Nov 2016 16:48:01 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:

> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
> 
> > Add symbol to mark end of entry_*.S and use the same to blacklist all
> > addresses from kernel start (_stext) to entry code from kprobes. Much of
> > this code is early exception handling where we can't really take a trap.
> 
> I'm not sure about this. entry_*.S is actually a bit of jumble,
> especially the 64bit version. I've been wanting to split it up for a
> long time.
> 
> It doesn't actually contain any early exception handling. It does
> contain the common syscall handler, and the exception return paths, some
> of which should be black listed. And lots of other junk.
> 
> Also I'm not sure if it's guaranteed that there won't be other code
> between _stext and the end of entry, it's not handled explicitly in the
> linker script, it just tends to get linked early because it's in head-y.
> 
> So I think it would be better if we had a clearer picture of exactly
> what in this file we want to blacklist.

Fair enough.

OK, the purpose of the kprobe blacklist is to avoid crashing kernel
by putting kprobes in some critical area (critical for kprobes,
not what usually "critical region" means).

Since kprobes is using breakpoint(trap) exception, if there is another
kprobes(trap) on the path until kprobe_handler() handle it, the kernel
kicks same exception handler and fall into the recursive fault.
So the blacklist is used in kprobe to prohibit putting kprobes on such
functions for avoiding it.

So, we might be carefully choose the function for the blacklist.

BTW, Naveen, as far as I can see the kprobe implementation on ppc,
it still depends on exceptions_notify to handle trap. It is no more
recommended becuase notifier_call_chain involves too many unrelated
functions. I recommend you to callback kprobe_handler and
kprobe_post_handler directly from the trap handler as same as x86.

Unless that, kprobe_blacklist may not work.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

  reply	other threads:[~2016-11-18  7:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17 15:08 [RFC PATCH 0/4] Blacklist powerpc exception vectors from kprobes Naveen N. Rao
2016-11-17 15:08 ` [RFC PATCH 1/4] powerpc: asm: introduce new macros for assembly globals Naveen N. Rao
2016-11-18  9:41   ` Michael Ellerman
2016-11-18 11:36     ` Naveen N. Rao
2016-11-17 15:08 ` [RFC PATCH 2/4] powerpc: kprobe: add arch specific blacklist Naveen N. Rao
2016-11-18  5:48   ` Michael Ellerman
2016-11-18  7:04     ` Masami Hiramatsu [this message]
2016-11-18 11:24       ` Naveen N. Rao
2016-11-18 11:22     ` Naveen N. Rao
2016-11-17 15:08 ` [RFC PATCH 3/4] powerpc: mm/slb: convert slb_low.S to use the new macros Naveen N. Rao
2016-11-17 15:08 ` [RFC PATCH 4/4] powerpc: mm/slb: blacklist symbols from kprobe Naveen N. Rao
2016-11-18  9:36   ` Michael Ellerman
2016-11-18 11:26     ` Naveen N. Rao

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=20161118160427.c1fa43473cd96e0bcc3b35a6@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=ananth@in.ibm.com \
    --cc=anton@samba.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).