On 2017/04/27 11:24AM, Masami Hiramatsu wrote:

Hello Naveen,

On Tue, 25 Apr 2017 22:04:05 +0530
"Naveen N. Rao" [off-list ref] wrote:

quoted

This is the second in the series of patches to build out an appropriate
kprobes blacklist. This series blacklists system_call() and functions
involved when handling the trap itself. Not everything is covered, but
this is the first set of functions that I have tested with. More
patches to follow once I expand my tests.

OK, btw, have you tested to put kprobes on these functions and
saw kernel panic happened?

Thanks for the question! I re-checked and I just realized I hadn't 
tested the PAPR case (stolen time accounting). On testing, I just found 
that those functions are not a problem since they are only invoked when 
we are coming in from user-space and not when we take a trap in-kernel.  
I will re-spin patch 3/4. Other functions have been tested to cause 
issues with kprobes.

There are still a few more functions involved (especially with 
CONFIG_PREEMPT) where I couldn't reproduce an issue, so I haven't 
included those in this series.  I am continuing to test this further and 
will post subsequent patches once I work out which other functions are 
problematic.

quoted

I have converted many labels into private -- these are labels that I
felt are not necessary to read stack traces. If any of those are
important to have, please let me know.

At least from the viewpoint of kprobe-blacklist macros, it seems
good to me :)

Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>

for this series.

Thank you,

Thanks for the review!
- Naveen