All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	don <zds100@gmail.com>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] tracing/fprobe: Support raw tracepoint events on modules
Date: Tue, 4 Jun 2024 12:34:18 -0400	[thread overview]
Message-ID: <20240604123418.22e16e97@gandalf.local.home> (raw)
In-Reply-To: <419b80da-9cbf-4bb2-aabb-dc04f0fb0f37@efficios.com>

On Tue, 4 Jun 2024 11:02:16 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> I see.
> 
> It looks like there are a few things we could improve there:
> 
> 1) With your approach, modules need to be already loaded before
> attaching an fprobe event to them. This effectively prevents
> attaching to any module init code. Is there any way we could allow
> this by implementing a module coming notifier in fprobe as well ?
> This would require that fprobes are kept around in a data structure
> that matches the modules when they are loaded in the coming notifier.

The above sounds like a nice enhancement, but not something necessary for
this series.

> 
> 2) Given that the fprobe module going notifier is protected by the
> event_mutex, can we use locking rather than reference counting
> in fprobe attach to guarantee the target module is not reclaimed
> concurrently ? This would remove the transient side-effect of
> holding a module reference count which temporarily prevents module
> unload.

Why do we care about unloading modules during the transition? Note, module
unload has always been considered a second class citizen, and there's been
talks in the past to even rip it out.

-- Steve

  reply	other threads:[~2024-06-04 16:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-01  8:22 [PATCH v2 0/3] tracing/probes: Support tracepoint events on modules Masami Hiramatsu (Google)
2024-06-01  8:22 ` [PATCH v2 1/3] tracepoint: Support iterating over tracepoints " Masami Hiramatsu (Google)
2024-06-01  8:22 ` [PATCH v2 2/3] tracing/fprobe: Support raw tracepoint events " Masami Hiramatsu (Google)
2024-06-03 19:50   ` Mathieu Desnoyers
2024-06-03 21:50     ` Steven Rostedt
2024-06-03 23:49     ` Masami Hiramatsu
2024-06-04 15:02       ` Mathieu Desnoyers
2024-06-04 16:34         ` Steven Rostedt [this message]
2024-06-04 18:03           ` Mathieu Desnoyers
2024-08-14  2:01             ` Masami Hiramatsu
2024-06-04 15:12       ` Steven Rostedt
2024-06-01  8:22 ` [PATCH v2 3/3] sefltests/tracing: Add a test for " Masami Hiramatsu (Google)
2024-06-04 15:21   ` Steven Rostedt

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=20240604123418.22e16e97@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=zds100@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.