]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
tracing: Fix using ret variable in tracing_set_tracer()
authorSteven Rostedt <rostedt@goodmis.org>
Mon, 6 Jan 2025 16:11:43 +0000 (11:11 -0500)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 27 Feb 2025 12:30:24 +0000 (04:30 -0800)
commit384c8291f7ceda834bae1ee445057bdee7c1940d
tree18b5b5bbb9ff95630d6a05771c1a02de8f619ee9
parent67cb8eaafca15bb20b587a68bbf0edf3d959d32c
tracing: Fix using ret variable in tracing_set_tracer()

commit 22bec11a569983f39c6061cb82279e7de9e3bdfc upstream.

When the function tracing_set_tracer() switched over to using the guard()
infrastructure, it did not need to save the 'ret' variable and would just
return the value when an error arised, instead of setting ret and jumping
to an out label.

When CONFIG_TRACER_SNAPSHOT is enabled, it had code that expected the
"ret" variable to be initialized to zero and had set 'ret' while holding
an arch_spin_lock() (not used by guard), and then upon releasing the lock
it would check 'ret' and exit if set. But because ret was only set when an
error occurred while holding the locks, 'ret' would be used uninitialized
if there was no error. The code in the CONFIG_TRACER_SNAPSHOT block should
be self contain. Make sure 'ret' is also set when no error occurred.

Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://lore.kernel.org/20250106111143.2f90ff65@gandalf.local.home
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202412271654.nJVBuwmF-lkp@intel.com/
Fixes: d33b10c0c73ad ("tracing: Switch trace.c code over to use guard()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kernel/trace/trace.c