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
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