linux.git/kernel/trace/ftrace.c, branch v7.3-rc2

ftrace: Synchronize the initialization of ftrace_ops

2026-09-02T15:08:21+00:00

There's some internal state that ftrace_ops needs to have set, but since
it can be declared outside of the ftrace.c code, it calls
ftrace_ops_init() on the ops in every global function. The issue is that
if two tasks call it on the same ops at the same time it is possible to
have the initialization of one corrupt the initialization of the other
call.

Create a ops_mutex to use to synchronize every initialization of the
ftrace_ops. The mutex is taken within checking the ftrace_ops flag that
states it was initializied but the flag is checked again after the mutex
has been taken. Checking first outside the mutex allows it to shortcut
having to take the mutex. But then the check needs to be done again after
the mute is taken in case of races.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260902095501.6b59af20@gandalf.local.home
Fixes: f04f24fb7e48d ("ftrace, kprobes: Fix a deadlock on ftrace_regex_lock")
Reported-by: sashiko-bot@kernel.org
Close: https://lore.kernel.org/all/20260829025528.49A831F000E9@smtp.kernel.org/
Signed-off-by: Steven Rostedt

ftrace: Take trace_array reference before accessing its ftrace_ops

2026-09-01T20:38:19+00:00

The trace instance files set_ftrace_filter and set_ftrace_notrace was
updated to work with specific trace instances (trace_arrays). The issue is
that when these files are opened, there is a small race window where it
will use the ftrace_ops from the inode->private pointer to get a reference
to the trace_array and then take its reference. The problem is that the
ftrace_ops itself could be freed. If the rmdir on the instance happens at
the same time the set_ftrace_filter file is opened, the rmdir could have
also freed the ftrace_ops and referencing it will cause a use-after-free
bug and crash the kernel.

Instead, pass in the trace_array as the file private data (NULL for the
top level instance), and then pass both the trace_array and the ftrace_ops
to the ftrace_regex_open() function. If the trace_array is NULL, then it
just uses the ftrace_ops without the need to take its reference (like
normal). If the ftrace_ops is NULL, that is only the case for the top
level instance and the global_ops can be used.

This allows the trace_array to have its reference incremented before
touching the ftrace_ops that could also be freed when the instance is.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260828223901.29e26edb@robin
Fixes: 591dffdade9f0 ("ftrace: Allow for function tracing instance to filter functions")
Reported-by: Breno Leitao 
Tested-by: Breno Leitao 
Closes: https://lore.kernel.org/all/apGORjltZgAiAYHT@gmail.com/
Signed-off-by: Steven Rostedt

Merge tag 'ftrace-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

2026-08-19T21:01:58+00:00

Pull ftrace updates from Steven Rostedt:

 - Deprecrate ftrace_enabled in disabling ftrace

   The file /proc/sys/kernel/ftrace_enabled was created when ftrace was
   first introduced back in 2008. It was to be a "kill switch" if
   something was to go wrong. It was also used as a way to turn off
   function tracing for the latency tracers that would have it on by
   default. But in 2013 (Linux 3.10) the option "function-trace" was
   introduced to disable function tracing for the latency tracers as the
   "ftrace_enabled" file was considered too big of a hammer and caused
   too many side effects.

   When live kernel patching came along, disabling ftrace via the
   ftrace_enabled file would put the system into an unstable state if a
   live kernel patch was installed. This created the need to mark some
   function hooks as "PERMANENT".

   Now there's a need for BPF usage marked as PERMANENT for the same
   reasons.

   The file "ftrace_enabled" usage is no longer viable. It doesn't do
   what it says it does and there is no reason to use it.

   Make writing '0' to it a nop and print a message saying its usage is
   deprecated. The return value of writing '0' is -EOPNOTSUPP so that
   user space will error on that write (hopefully to inform any
   developer that it no longer works).

   Eventually the file should be removed completely, but for now just
   making it not do anything is the path forward to that.

 - Update the livepatch tests to handle ftrace_enabled being disabled

   Because in the past, livepatch was broken by ftrace_enabled being
   turned off, there's a test case that checks to make sure it still
   doesn't break. But having the write of '0' return an error caused
   that test to break. Updated the test to handle the new change.

* tag 'ftrace-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  selftests/livepatch: update test-ftrace.sh for deprecated ftrace_enabled
  ftrace: deprecate disabling via ftrace_enabled sysctl

ftrace: deprecate disabling via ftrace_enabled sysctl

2026-08-11T01:21:18+00:00

Writing 0 to kernel.ftrace_enabled has not reliably disabled ftrace
for years (FTRACE_OPS_FL_PERMANENT users already block it, and more
callers rely on ftrace always being on). Refuse the write instead of
leaving it in an inconsistent "disables some, not all" state: return
-EOPNOTSUPP and log a message. Reads and enabling (writing 1) are
unaffected.

Update the docs to note the deprecation up front.

Link: https://patch.msgid.link/20260806153000.4184871-2-andrey.grodzovsky@crowdstrike.com
Suggested-by: Steven Rostedt 
Signed-off-by: Andrey Grodzovsky 
Acked-by: Song Liu 
Signed-off-by: Steven Rostedt

ftrace: Fix off-by-one fentry site disable in ftrace_free_mem()

2026-08-09T02:22:41+00:00

When a module's init text is freed, do_init_module() calls
ftrace_free_mem() with a half-open [start, end) range.  However the
ftrace_cmp_recs() comparator treats the upper bound as inclusive, as all
its other users do, passing 'ip + size - 1'.  So ftrace_free_mem() can
delete a record sitting exactly at 'end', which is outside the freed
range.

For a kernel without CFI or IBT, the first record of a function is at
the function start, which for the first function in a module is also the
base of its text allocation.  As the module allocator packs its regions,
that address is often the 'end' passed by a neighboring module's
do_init_module(), causing the first function's ftrace location to get
disabled, preventing an attempt to livepatch it:

  livepatch: failed to find location for function 'pcspkr_probe'

Convert the exclusive end to the inclusive 'end - 1' the comparator
expects, and return early for an empty range to avoid the subtraction
from underflowing when the init text size is zero.

Cc: stable@vger.kernel.org
Fixes: 42c269c88dc1 ("ftrace: Allow for function tracing to record init functions on boot up")
Link: https://patch.msgid.link/1b5ccfa8095bdb1277f84af1c2c2e2205aca03ae.1785992188.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf 
Acked-by: Masami Hiramatsu (Google) 
Signed-off-by: Steven Rostedt

ftrace: Protect direct_functions in update_ftrace_direct_mod

2026-08-08T15:21:27+00:00

Fix accessing the __rcu pointer direct_functions with RCU protection.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260730150411.88667-4-leon.hwang@linux.dev
Fixes: e93672f770d7 ("ftrace: Add update_ftrace_direct_mod function")
Acked-by: Jiri Olsa 
Signed-off-by: Leon Hwang 
Signed-off-by: Steven Rostedt

ftrace: Protect direct_functions in update_ftrace_direct_del

2026-08-08T15:21:23+00:00

Fix accessing the __rcu pointer direct_functions with RCU protection.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260730150411.88667-3-leon.hwang@linux.dev
Fixes: 8d2c1233f371 ("ftrace: Add update_ftrace_direct_del function")
Acked-by: Jiri Olsa 
Signed-off-by: Leon Hwang 
Signed-off-by: Steven Rostedt

ftrace: Protect direct_functions in ftrace_find_rec_direct

2026-08-08T15:21:04+00:00

Fix accessing the __rcu pointer direct_functions with RCU protection.

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260730150411.88667-2-leon.hwang@linux.dev
Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use")
Acked-by: Jiri Olsa 
Suggested-by: Steven Rostedt 
Signed-off-by: Leon Hwang 
Signed-off-by: Steven Rostedt

ftrace: Add global mutex to serialize trace_parser access

2026-07-25T02:56:43+00:00

In ftrace, the trace_parser structure is allocated and initialized when
a trace file is opened, and is subsequently used across write and release
handlers to parse user input.

The affected handler paths and their specific functions are:
  - Open paths: ftrace_regex_open(), ftrace_graph_open()
  - Write paths: ftrace_regex_write(), ftrace_graph_write()
  - Release paths: ftrace_regex_release(), ftrace_graph_release()

If userspace opens a trace file descriptor and shares it across multiple
threads, concurrent write calls will race on the parser's internal state,
specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted
input or undefined behavior.

Fix this by adding a global mutex, parser_lock, to serialize all access
to trace_parser across write and release paths, preventing concurrent
corruption of parser state.

Fixes: e704eff3ff51 ("ftrace: Have set_graph_function handle multiple functions in one write")
Fixes: 689fd8b65d66 ("tracing: trace parser support for function and graph")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260725024721.1983675-1-wutengda@huaweicloud.com
Signed-off-by: Tengda Wu 
Signed-off-by: Steven Rostedt

ftrace: Add add_ftrace_hash_entry function

2026-06-07T17:03:00+00:00

Renaming __add_hash_entry to add_ftrace_hash_entry and making it global,
it will be used in following changes outside ftrace.c object.

Signed-off-by: Jiri Olsa 
Link: https://lore.kernel.org/r/20260606123955.345967-4-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov