Messages in this thread | | | Date | Wed, 28 Apr 2010 11:39:40 -0400 | From | Masami Hiramatsu <> | Subject | 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
| |