[RFC PATCH 2/4] powerpc: kprobe: add arch specific blacklist

Masami Hiramatsu mhiramat at kernel.org
Fri Nov 18 18:04:27 AEDT 2016


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

> "Naveen N. Rao" <naveen.n.rao at 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 at kernel.org>


More information about the Linuxppc-dev mailing list