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

[Beau Belgrave]

On Wed, Oct 12, 2022 at 06:26:39PM -0400, Steven Rostedt wrote:
> On Wed, 12 Oct 2022 14:57:17 -0700
> Beau Belgrave <beaub@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> > When events are enabled via the "enable" file within tracefs there is no
> > get or put ref. Add these to ensure modules and dynamic events do not
> > unload while the event is enabled via tracefs.
> 
> Why is this an issue?

It depends on the scenario, it may or may not cause a issue.

> 
> 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().

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?

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?

> 
> -- Steve

Thanks,
-Beau