On 2017/04/27 11:24AM, Masami Hiramatsu wrote: > Hello Naveen, > > On Tue, 25 Apr 2017 22:04:05 +0530 > "Naveen N. Rao" <naveen.n....@linux.vnet.ibm.com> wrote: > > > 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. > > > 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 <mhira...@kernel.org> > > for this series. > > Thank you, Thanks for the review! - Naveen