Re: [RFC][Patch 0/2]kprobe: kprobe-booster against 2.6.14-mm1 for i386

[Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>]

Hi,

Keshavamurthy Anil S wrote:
> On Fri, Nov 25, 2005 at 05:12:59AM -0800, Masami Hiramatsu wrote:
> Cool!! Before I look at your patch(which I will do later today), I had
> a question for you. With this patch, does kprobes still works with CONFIG_PREEMPT=y?
> Or in other words, do you expect preeempt to be disabled for your patch to work?

Currently it may not work perfectly with preemptable kernel.
I would like to discuss about it.
The problem is releasing timing. If an interruption is
occurred when a process is executing directly the copied
code, the address of instruction buffer is pushed in the
stack. After that, if the process is scheduled (preempted),
we can not release the instruction buffer.
I am considering the ideas to avoid this problem.


By the way, I think the original kprobes has a smp racing
problem.
On SMP machine, a CPU (CPU0) can unregister that kprobe
and release its instruction buffer, even if another CPU
(CPU1) is executing kprobe_handler(). In this case, CPU1
will execute released instructions.
I found the kprobe just uses synchronize_sched() function.
And I guess the kprobes uses this function to resolve the
problem. If it is correct, how does this function resolve
the problem?

Best Regards,

-- 
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp