Messages in this thread | | | Date | Tue, 10 Mar 2020 11:46:57 -0400 | From | Steven Rostedt <> | Subject | Re: Instrumentation and RCU |
| |
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
| |