On 2/27/26 1:24 PM, Jiri Olsa wrote: > On Fri, Feb 27, 2026 at 09:37:52PM +0100, Jiri Olsa wrote: >> [...] >> >>> >>> With CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS ftrace_replace_code() >>> operates on all call sites in the shared ops. Then if a concurrent >>> ftrace user (like kprobe) modifies a call site in between >>> ftrace_replace_code's verify pass and its patch pass, then ftrace_bug >>> fires and sets ftrace_disabled to 1. >> >> hum, I'd think that's all under ftrace_lock/direct_mutex, >> but we might be missing some paths >> > > could you please try with change below? I can no longer trigger the bug with > it
Can confirm that the bug doesn't trigger with this change. At least by the reproducer test. Tested-by: Ihor Solodrai <[email protected]> Thanks! > > thanks, > jirka > > > --- > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > index 827fb9a0bf0d..e333749a5896 100644 > --- a/kernel/trace/ftrace.c > +++ b/kernel/trace/ftrace.c > @@ -6404,7 +6404,9 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, > struct ftrace_hash *hash) > new_filter_hash = old_filter_hash; > } > } else { > + mutex_lock(&ftrace_lock); > err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH); > + mutex_unlock(&ftrace_lock); > /* > * new_filter_hash is dup-ed, so we need to release it anyway, > * old_filter_hash either stays on error or is already released > @@ -6530,7 +6532,9 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, > struct ftrace_hash *hash) > ops->func_hash->filter_hash = NULL; > } > } else { > + mutex_lock(&ftrace_lock); > err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH); > + mutex_unlock(&ftrace_lock); > /* > * new_filter_hash is dup-ed, so we need to release it anyway, > * old_filter_hash either stays on error or is already released
