lkml.org 
[lkml]   [2020]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2020-03-10 16:47    [W:0.079 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site