Re: [PATCH] tracing: Track event ref in tracefs enable/disable

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 12 Oct 2022 17:19:38 -0700
Beau Belgrave <beaub@linux.microsoft.com> wrote:

> > 
> > The events are only called from the module code, and when the module is
> > unloaded, they are no longer called. Why keep the module from unloading
> > when enabled?  
> 
> Won't the modules remove the event calls? At the very least the event
> call structure in memory goes away during module unload. If it gets
> reused odd things will happen, right? IE: trace_module_remove_events().

Yes it gets removed along with the module. But everything about the
static event is part of the module.

> 
> Maybe I have a bad assumption:
> I thought the point of trace_event_try_get_ref()/put_ref() was to tell
> the system the call cannot go away. However, if ftrace enable doesn't
> use these the lifetime is ambigious in this case. If this was
> intentional, how are event call lifetimes described if not within the
> ref?
> 

The purpose of trace_event_try_get_ref and friends is for the case of
dynamic events (eprobes and synthetic events) that can attach to any
event (including module events), and the module removal does not remove
the dynamic portion that was attached to them. And in this case, the
removal would have dire results.

> In my namespace patches I hit this case when user_events try to go away
> during namespace teardown. Since there is no reference to the event
> being used I removed the call. However, it was clearly being used within
> tracefs at that point. When I cat "enable" in this case instead of "0"
> or "1" I get "?". I suppose worse things could happen when the memory of
> the call gets reused?
>

Could you have a callback telling tracefs that it is going away (like
the module notifier does)?

-- Steve