Hi Masami, On 2016/11/18 04:04PM, Masami Hiramatsu wrote: > On Fri, 18 Nov 2016 16:48:01 +1100 > Michael Ellerman <m...@ellerman.id.au> wrote: > > > "Naveen N. Rao" <naveen.n....@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
