Messages in this thread |  | | From | Yun Levi <> | | Date | Wed, 4 May 2022 12:28:01 +0900 | | Subject | Re: [PATCH] kprobe: sync issue's on ftraced-kprobe. |
| |
> 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.
|  |