Re: [PATCH v4] [RFC] trace: Add kprobe on tracepoint

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 12 Aug 2021 20:31:10 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> > Yes, anyway we need a way to find loops on histogram/eprobe at last.  
> 
> BTW, what about using similar machanism of "current_kprobe()" to detect
> the reccursion? As an easy way, prepare a static per-cpu pointer which sets
> the current eprobe and if the eprobe handler detects that is already set,
> it may warn (or silently ignore) and reject it.
> (Of course it is better to detect the loop when user sets the hist-trigger
> by reverse link)

Thinking more about this, I believe there is a use case for synthetic
event on a eprobe. Basically:

  normal_event -> eprobe (extracts struct data into $dat) -> onmax($dat) -> synthetic event

But I can not come up with any use case of:

  eprobe -> synthetic event -> eprobe

or

  synthetic event -> eprobe -> synthetic event

That's because once you have an eprobe, you can extract what you want,
and once you have that synthetic event, you can get the data you want.

Maybe we should prevent the above and allow one eprobe on a synthetic
event and one synthetic event on an eprobe.

Or just don't prevent it at all, and let the user shoot themselves in
the foot ;-)

The more I think about this, I'm thinking we just let them shoot
themselves if they want to.

But I still agree that eprobes should not be attached to kprobes or
uprobes directly (although they may be able to be attached to a
synthetic event that is attached to one!)

-- Steve