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

[Naveen N. Rao]

Hi Masami,

On 2016/11/18 04:04PM, Masami Hiramatsu wrote:
> 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.

Agreed, though in this case, I'm trying to blacklist early exception 
code to begin with :)

> 
> 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.

Ah, thanks for the tip. Patch to follow.


- Naveen