LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>,
	linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
	tom.zanussi@linux.intel.com
Subject: Re: [PATCH v4] [RFC] trace: Add kprobe on tracepoint
Date: Thu, 12 Aug 2021 09:44:39 -0400	[thread overview]
Message-ID: <20210812094439.56303efa@oasis.local.home> (raw)
In-Reply-To: <20210812203110.3c82c040104e0fb488912ee1@kernel.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

  reply	other threads:[~2021-08-12 13:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-11 14:14 Tzvetomir Stoyanov (VMware)
2021-08-11 15:03 ` Masami Hiramatsu
2021-08-11 15:22   ` Steven Rostedt
2021-08-12  1:27     ` Masami Hiramatsu
2021-08-12  3:46       ` Steven Rostedt
2021-08-12  9:44         ` Masami Hiramatsu
2021-08-12 11:14           ` Masami Hiramatsu
2021-08-12  4:02       ` Steven Rostedt
2021-08-12 11:15         ` Masami Hiramatsu
2021-08-12 11:31       ` Masami Hiramatsu
2021-08-12 13:44         ` Steven Rostedt [this message]
2021-08-12 15:06           ` Masami Hiramatsu
2021-08-12 15:44 ` Masami Hiramatsu
2021-08-16 21:40   ` Steven Rostedt
2021-08-17 11:52     ` Masami Hiramatsu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210812094439.56303efa@oasis.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=tom.zanussi@linux.intel.com \
    --cc=tz.stoyanov@gmail.com \
    --subject='Re: [PATCH v4] [RFC] trace: Add kprobe on tracepoint' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).