On Wed, 2026-05-27 at 11:37 -0400, Steven Rostedt wrote: > 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? >
I don't think this patch has any particular urgency. It can go in using whatever flow is most convenient. -- All Rights Reversed.
