Re: Instrumentation and RCU

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 10 Mar 2020 11:31:51 -0400 (EDT)
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> I think there are two distinct problems we are trying to solve here,
> and it would be good to spell them out to see which pieces of technical
> solution apply to which.
> 
> Problem #1) Tracer invoked from partially initialized kernel context
> 
>   - Moving the early/late entry/exit points into sections invisible from
>     instrumentation seems to make tons of sense for this.
> 
> Problem #2) Tracer recursion
> 
>   - I'm much less convinced that hiding entry points from instrumentation
>     works for this. As an example, with the isntr_begin/end() approach you
>     propose above, as soon as you have a tracer recursing into itself because
>     something below do_stuff() has been instrumented, having hidden the entry
>     point did not help at all.
> 
> So I would be tempted to use the "hide entry/exit points" with explicit
> instr begin/end annotation to solve Problem #1, but I'm still thinking there
> is value in the per recursion context "in_tracing" flag to prevent tracer
> recursion.

The only recursion issue that I've seen discussed is breakpoints. And
that's outside of the tracer infrastructure. Basically, if someone added a
breakpoint for a kprobe on something that gets called in the int3 code
before kprobes is called we have (let's say rcu_nmi_enter()):


 rcu_nmi_enter();
  <int3>
     do_int3() {
        rcu_nmi_enter();
          <int3>
             do_int3();
                [..]

Where would a "in_tracer" flag help here? Perhaps a "in_breakpoint" could?

-- Steve