Rik,
Can you reply to Sashiko here? The below comes from Sashiko: https://sashiko.dev/?list=org.kernel.vger.linux-trace-kernel#/patchset/20260513161916.04151502%40fangorn Thanks, -- Steve > commit f90ac36f39b79a19c015522bb1caf7ef903caf02 > Author: Rik van Riel <[email protected]> > perf/ftrace: Fix WARNING in __unregister_ftrace_function > This commit attempts to fix a WARN_ON triggered during perf_event_alloc() > error > cleanup by checking FTRACE_OPS_FL_ENABLED before unregistering the ftrace > function. The warning occurs because the ftrace_ops registration failed or was > torn down by perf_try_init_event() earlier, but the event->destroy callback is > executed again during the error path. > > diff --git a/kernel/trace/trace_event_perf.c > > b/kernel/trace/trace_event_perf.c > > index 61e3a2620fa3c..8d64f17135e8f 100644 > > --- a/kernel/trace/trace_event_perf.c > > +++ b/kernel/trace/trace_event_perf.c > > @@ -495,7 +495,11 @@ static int perf_ftrace_function_register(struct > > perf_event *event) > > static int perf_ftrace_function_unregister(struct perf_event *event) > > { > > struct ftrace_ops *ops = &event->ftrace_ops; > > - int ret = unregister_ftrace_function(ops); > > + int ret = 0; > > + > > + if (ops->flags & FTRACE_OPS_FL_ENABLED) > > + ret = unregister_ftrace_function(ops); > > + > > ftrace_free_filter(ops); > Does calling ftrace_free_filter() unconditionally here mask a double-teardown > regression while leaving the underlying double-free active? > In perf_try_init_event(), if a PMU event_init() succeeds but a subsequent > capability check fails, it explicitly calls event->destroy(event) to roll > back: > kernel/events/core.c:perf_try_init_event() { > ... > if (ret && event->destroy) > event->destroy(event); > ... > } > However, it does not set event->destroy to NULL. > When the event is later freed in error paths, the stale event->destroy > callback > executes a second time. > If ftrace_free_filter() is called twice, won't it result in a direct > double-free of ops->func_hash->filter_hash, since ftrace_free_filter() frees > the hash but does not nullify the pointers? > Additionally, for regular tracepoint events, wouldn't the second teardown > execute perf_trace_event_unreg() again? > This could double-decrement total_ref_count, potentially freeing the shared > perf_trace_buf while other events are active, and trigger an unbalanced > module_put() leading to module refcount underflows. > Should the root cause be addressed by setting event->destroy = NULL in > perf_try_init_event() immediately after invoking it? > > return ret; > > }
