Re: [PATCH] kprobe: sync issue's on ftraced-kprobe.

[Yun Levi]

> NAK this, because get_kprobes() doesn't require the kprobe_mutex in
> the preempt-disabled context. Please read the comment of get_kprobe().
>
> /*
>  * This routine is called either:
>  *      - under the 'kprobe_mutex' - during kprobe_[un]register().
>  *                              OR
>  *      - with preemption disabled - from architecture specific code.
>  */
> struct kprobe *get_kprobe(void *addr)

> Moreover, we can not use mutex inside kprobe handler because it runs
> in the interrupt context.

Actually, I think it's in the preemption disabled in situation.
What I mentioned is actually it seems inside the kprobe handler which
installed via ftrace isn't interrupt context.

#ifdef CONFIG_KPROBES_ON_FTRACE
static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
 >---.func = kprobe_ftrace_handler,
 >---.flags = FTRACE_OPS_FL_SAVE_REGS,
 };

In case of optimized kprobe it disables preemption when it enter
"optimized callback"
And the trampoline isn't the interrupted context.
It's also the same to install kprobe via ftraced .
When I see the ftraced patched code, I couldn't find any interrupt and
preemption disable code.
But it seems to allow preemption in ftarce handler.
(In the ftrace_reg_caller, ftace_reg_end, and other ftrace trampoline code also)

What I understand is break point based kprobe is only interrupted
disabled status
But optimized kprobe and ftarced kprobe isn't interrupted disabled status.
For this, optimized kprobe disable disable preemption in "optimized_callback"

But ftrace kprobe isn't preemption disabled nor interrupt-disabled context.

That's why I sent patches and I experienced the problem above.

Am I missing something?

Thx.