Re: [PATCH v2 3/9] rcu,tracing: Create trace_rcu_{enter,exit}()

From: Masami Hiramatsu
Date: Tue Feb 18 2020 - 21:45:18 EST


On Tue, 18 Feb 2020 12:18:06 -0800
"Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:

> On Tue, Feb 18, 2020 at 12:46:09PM -0500, Steven Rostedt wrote:
> > On Tue, 18 Feb 2020 13:33:35 +0900
> > Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote:
> >
> > > On Mon, 17 Feb 2020 08:31:12 -0800
> > > "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> > > >
> > > > > BTW, if you consider the x86 specific code is in the generic file,
> > > > > we can move NOKPROBE_SYMBOL() in arch/x86/kernel/traps.c.
> > > > > (Sorry, I've hit this idea right now)
> > > >
> > > > Might this affect other architectures with NMIs and probe-like things?
> > > > If so, it might make sense to leave it where it is.
> > >
> > > Yes, git grep shows that arm64 is using rcu_nmi_enter() in
> > > debug_exception_enter().
> > > OK, let's keep it, but maybe it is good to update the comment for
> > > arm64 too. What about following?
> > >
> > > +/*
> > > + * All functions in do_int3() on x86, do_debug_exception() on arm64 must be
> > > + * marked NOKPROBE before kprobes handler is called.
> > > + * ist_enter() on x86 and debug_exception_enter() on arm64 which is called
> > > + * before kprobes handle happens to call rcu_nmi_enter() which means
> > > + * that rcu_nmi_enter() must be marked NOKRPOBE.
> > > + */
> > >
> >
> > Ah, why don't we just say...
> >
> > /*
> > * All functions called in the breakpoint trap handler (e.g. do_int3()
> > * on x86), must not allow kprobes until the kprobe breakpoint handler
> > * is called, otherwise it can cause an infinite recursion.
> > * On some archs, rcu_nmi_enter() is called in the breakpoint handler
> > * before the kprobe breakpoint handler is called, thus it must be
> > * marked as NOKPROBE.
> > */
> >
> > And that way we don't make this an arch specific comment.
>
> That looks good to me. Masami, does this work for you?

Yes, that looks good to me too :)

Thank you!


--
Masami Hiramatsu <mhiramat@xxxxxxxxxx>