This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip 2/2] [BUGFIX] kprobes/x86: Fix removed int3 checking order
Ananth N Mavinakayanahalli wrote:
> On Tue, Apr 27, 2010 at 06:33:49PM -0400, Masami Hiramatsu wrote:
>> Fix kprobe/x86 to check removed int3 when failing to get kprobe
>> from hlist. Since we have a time window between checking int3
>> exists on probed address and getting kprobe on that address,
>> we can have following senario.
>> -------
>> CPU1 CPU2
>> hit int3
>> check int3 exists
>> remove int3
>> remove kprobe from hlist
>> get kprobe from hlist
>> no kprobe->OOPS!
>> -------
>
> Do you have a testcase for this issue?
I heard this issue was found by systemtap team on stable kernel(means
no jump optimization). Their testsuites caused an oops (but not 100%
reproducible) with "pr10854" testcase, which registers over 5000
probes at once and removes it soon.
>> This patch moves int3 checking if there is no kprobe on that
>> address for fixing this problem as follows;
>> ------
>> CPU1 CPU2
>> hit int3
>> remove int3
>> remove kprobe from hlist
>> get kprobe from hlist
>> no kprobe->check int3 exists
>> ->rollback&retry
>> ------
>
> You may also want to fix up the comment on top of kprobe_handler() about
> the interrupt gate as its only true for x86_32 and not x86_64, right?
Hmm, I couldn't find it, could you tell me more details?
(and maybe, it's another issue)
what I could find is int3 handler is registered as interrupt gate
on both of x86-32/64.
void __init trap_init(void)
{
...
/* int3 can be called from all */
set_system_intr_gate_ist(3, &int3, DEBUG_STACK);
>
>> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
>> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
>> Cc: Dave Anderson <anderson@redhat.com>
>> Cc: Ingo Molnar <mingo@elte.hu>
>
> Acked-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Thank you,
--
Masami Hiramatsu
e-mail: mhiramat@redhat.com