Messages in this thread | | | Date | Fri, 01 Jul 2011 14:09:22 +0900 | From | Masami Hiramatsu <> | Subject | Re: [RFC][PATCH] kprobes: Add separate preempt_disabling for kprobes |
| |
(2011/07/01 0:51), Steven Rostedt wrote: > Kprobes requires preemption to be disabled as it single steps the code > it replaced with a breakpoint. But because the code that is single > stepped could be reading the preempt count, the kprobe disabling of the > preempt count can cause the wrong value to end up as a result. Here's an > example: > > If we add a kprobe on a inc_preempt_count() call:
BTW, on my tip tree, add_preempt_count (a.k.a. inc_preempt_count()) is marked as __kprobes, so it can not be probed. Is there any change?
Anyway, I'll send the removing preempt_disable from kprobe patch.
Thank you,
> > [ preempt_count = 0 ] > > ld preempt_count, %eax <<--- trap > > <trap> > preempt_disable(); > [ preempt_count = 1] > setup_singlestep(); > <trap return> > > [ preempt_count = 1 ] > > ld preempt_count, %eax > > [ %eax = 1 ] > > <trap> > post_kprobe_handler() > preempt_enable_no_resched(); > [ preempt_count = 0 ] > <trap return> > > [ %eax = 1 ] > > add %eax,1 > > [ %eax = 2 ] > > st %eax, preempt_count > > [ preempt_count = 2 ] > > > We just caused preempt count to increment twice when it should have only > incremented once, and this screws everything else up. > > To solve this, I've added a per_cpu variable called > kprobe_preempt_disabled, that is set by the kprobe code. If it is set, > the preempt_schedule() will not preempt the code. >
-- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
| |