Messages in this thread | | | Date | Tue, 14 Apr 2020 18:03:38 +0200 | From | Jiri Olsa <> | Subject | Re: [RFC] kretprobe: Prevent triggering kretprobe from within kprobe_flush_task |
| |
On Fri, Apr 10, 2020 at 09:31:59AM +0900, Masami Hiramatsu wrote:
SNIP
> > diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c > > index 4d7022a740ab..081d0f366c99 100644 > > --- a/arch/x86/kernel/kprobes/core.c > > +++ b/arch/x86/kernel/kprobes/core.c > > @@ -757,12 +757,33 @@ static struct kprobe kretprobe_kprobe = { > > .addr = (void *)kretprobe_trampoline, > > }; > > > > +void arch_kprobe_reject_section_start(void) > > +{ > > + struct kprobe_ctlblk *kcb; > > + > > + preempt_disable(); > > + > > + /* > > + * Set a dummy kprobe for avoiding kretprobe recursion. > > + * Since kretprobe never run in kprobe handler, kprobe must not > > + * be running behind this point. > > + */ > > + __this_cpu_write(current_kprobe, &kretprobe_kprobe); > > + kcb = get_kprobe_ctlblk(); > > + kcb->kprobe_status = KPROBE_HIT_ACTIVE; > > +} > > Yeah, the code seems good to me. > > BTW, I rather like make it arch independent function so that other > arch can use it. In this case, the dummy kprobe's addr should be > somewhere obviously blacklisted (but it must be accessible.) > I think get_kprobe() will be a candidate.
right.. as Ziqian noted we see this on other ppc as well
> > And (sorry about changing my mind), the naming, I think kprobe_busy_begin() > and kprobe_busy_end() will be better because it doesn't reject registering > kprobes, instead, just make it busy :)
ok, will change
thanks, jirka
| |