reentrancy in post_handler problem in x86_64

["Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>]

Hi All,
	We had an AR item to help in resolving reentrancy while
servicing the post_handler of the first probe. After discussing the
issue with few x86_64 experts here at Intel, I now have two suggestions
to make.

Okay, before going to the possible suggestion, let me recap the problem
statement.

Problem Statement:
In the x86_86, when ever SingleStep/debug exception happens, the
hardware switches the stack to DEBUG_STACK. Due to this feature of
hardware,
when we are servicing the post_handler of the 1st probe ( at which point
we will be using DEBUG_STACK as we are servicing Singlestep/debug
exception) and as part of processing post_handler, if we encounter 2nd
probe and as part of supporting reentrancy in post_handler, if we try to
emulate the 2nd probe's original instruction we again will hit a
SingleStep/debug exception and at this point in time, the hardware
resets this DEBUG_STACK and we will loose the stack information for the
1st probe's post_hanlder. Basically we will encounter the stack
corruption.

Current Implementation to address the above issues:
	We are disarming the 2nd kprobe if we ever hit the 2nd kprobe
while we are still inside the post_handler of the 1st Kprobe. By
disarming the 2nd kprobe we are not even letting the user know what
caused his probe to get automatic disarm.

Intel's suggestion:
	Idea 1) In x86_64, we are setting a separate stack for Debug
exception. Don't do this, let Debug exception use the what ever stack it
was in prior to exception happens. i.e Don't use separate statck for
debug exceptions. Not sure how this will fly in the community and not a
recommended solution.

	Idea 2) Don't ever call your post_handler while in DEBUG_STACK,
i.e. before calling post_handler always switch to original parent stack,
i.e stack on which your pre_handler got executed.

Here is the possible design suggestion to implement idea number 2.

Step 1). After single stepping the first kprobe, set the ip to
trampoline_post_handler() and just do a normal return(which is an return
from interrupt) at which point we will
switch back to Original stack(i.e the stack on which the pre handler got
called) and the control goes to our trampoline_post_handler.
Step 2). Inside trampoline_post_handler(), create Interrupt frame and
pt_regs on the stack and call the kprobe->post_handler() and when you
get the control back from kprobe->post_handler(), do a normal rfi at
which point you should return to next instruction after the
probe(BREAK_INSTRUCTION) instruction.

Thanks,

-Anil Keshavamurthy
Sr. Software Engineer
Open Source Technology Center/SSG
Intel Corp.
(w) 503-712-4476