[lkml]   [2014]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH -tip 0/2] kprobes/x86: Fix bugs for NMI handling
The following series fixes bugs hidden in the ancient code.

The bugs suddenly appeared when I enabled over 6,000 kprobes
and ran perf-top with --call-graph. The bugs are hidden in
the old code and it have woken up by real stress testing.

Actually, current kprobes doesn't expect an NMI handler
hits in single-stepping state (including preparation and
do_debug() handling). Moreover, the NMI handler causing
a page fault by trying to access user pages, is out of
imagination! :) But perf does it.

Thus the previous code optimistically check the current
running kprobe state, and if it is in the singlestep state,
it changes the IP address to probed address and return,
because it expects the page fault happened on the single
stepped code.
However, in fact, the perf's NMI can interrupt the
do_debug or somewhere around that and it may cause a
page fault. In this case, putting the IP address to
probed address is simply wrong. It causes unexpected
kernel crash.
To handle this correctly, this patch fixes it to ensure
the page-fault address is actually same to the single-
stepping address, and only if so, set the IP address
to the probed address.

I also found another small mistake which gives up the
recovery from reentered kprobes in single-stepping state,
but it also assumes that there is no NMI handler interrupts
in that state. It should gives up only when the nested
reentering happens.

Thanks to Ingo and Frank for encouraging me to start
stress testing with massive multiple kprobes. :)

Thank you,


Masami Hiramatsu (2):
[BUGFIX]kprobes/x86: Fix page-fault handling logic
kprobes/x86: Allow to handle reentered kprobe on singlestepping

arch/x86/kernel/kprobes/core.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)


 \ /
  Last update: 2014-02-20 05:21    [W:0.043 / U:52.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site