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

Hi Masami,

On 2016/11/18 04:04PM, Masami Hiramatsu wrote:

On Fri, 18 Nov 2016 16:48:01 +1100
Michael Ellerman [off-list ref] wrote:

quoted

"Naveen N. Rao" [off-list ref] writes:

quoted

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