On Tue, 4 Jun 2024 11:02:16 -0400 Mathieu Desnoyers <mathieu.desnoy...@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
