Messages in this thread | | | Date | Fri, 01 Jul 2011 11:23:27 +0900 | From | Masami Hiramatsu <> | Subject | Re: [BUG] kprobes crashing because of preempt count |
| |
(2011/07/01 10:33), Steven Rostedt wrote: > On Fri, 2011-07-01 at 10:12 +0900, Masami Hiramatsu wrote: > >>> Do we really need to have preemption disabled throughout this? Is it >>> because we don't want to migrate or call schedule? Not sure what the >>> best way to fix this is. Perhaps we add a kprobe_preempt_disable() that >>> is checked as well? >> >> I think the best way to do that is just removing preemption disabling >> code, because >> - breakpoint exception itself disables interrupt (at least on x86) >> - While single stepping, interrupts also be disabled. > > I guess the above point is critical. If interrupts are disabled through > out the entire walk through, then we are fine, as that just guarantees > preemption is disabled anyway. But! if it does get enabled anywhere, > then we will have issues as the two traps require using the same state > data that is stored per cpu.
That should be a bug, or kprobe's assumption was so fragile (and must be rewritten.)
Anyway, kprobe_handler() in arch/x86/kernel/kprobes.c expects that it is executed in a critical section, and it ensures that if there is no other kprobes running on that processor. (however, as you can see in reenter_kprobe(), if the breakpoint hits under single stepping, it calls BUG() because kprobes guess that someone put another kprobe inside kprobe's critical section)
>> (BTW, theoretically, boosted and optimized kprobes shouldn't have >> this problem, because those doesn't execute single-stepping) > > Does the optimized kprobes even disable preemption?
Yeah, just while calling its handler, since someone will call may_sleep() in it... Anyway, nowadays it disables interruption for emulating breakpoint behavior.
>> >> So, I think there is no reason of disabling preemption. > > That would be the best solution.
Thank you,
-- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
| |