On Wed, 27 May 2026 11:13:01 -0400 Rik van Riel <[email protected]> wrote:
> perf_ftrace_function_unregister() unconditionally calls > unregister_ftrace_function() without checking whether the ftrace_ops > was ever successfully registered. This triggers a WARN_ON in > __unregister_ftrace_function() when the ops doesn't have > FTRACE_OPS_FL_ENABLED set. > > This can happen during perf_event_alloc() error cleanup when > perf_trace_destroy() is called via __free_event() on an event whose > ftrace_ops registration failed or was already torn down by > perf_try_init_event()'s err_destroy path. > > The call path is: > perf_event_alloc() error cleanup > -> __free_event() > -> event->destroy() [tp_perf_event_destroy] > -> perf_trace_destroy() > -> perf_trace_event_close() > -> TRACE_REG_PERF_CLOSE > -> perf_ftrace_function_unregister() > -> unregister_ftrace_function() > -> __unregister_ftrace_function() > -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) > > Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to > unregister. If the ops is not enabled, just free the filter and > return success. > > Signed-off-by: Rik van Riel <[email protected]> Thanks Rik. Is this urgent where it should have a Fixes tag and Cc stable as well as be sent to Linus during the -rc release, or can it wait for the next merge window? -- Steve
