Thread (13 messages) 13 messages, 3 authors, 2024-08-14

Re: [PATCH v2 2/3] tracing/fprobe: Support raw tracepoint events on modules

From: Steven Rostedt <rostedt@goodmis.org>
Date: 2024-06-04 16:34:23
Also in: lkml

On Tue, 4 Jun 2024 11:02:16 -0400
Mathieu Desnoyers [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help