On Wed, 12 Aug 2020 14:53:22 -0600 dann frazier dann.frazier@canonical.com wrote:
From: "Steven Rostedt (VMware)" rostedt@goodmis.org
commit 7ef282e05132d56b6f6b71e3873f317664bea78b upstream
If a process has the trace_pipe open on a trace_array, the current tracer for that trace array should not be changed. This was original enforced by a global lock, but when instances were introduced, it was moved to the current_trace. But this structure is shared by all instances, and a trace_pipe is for a single instance. There's no reason that a process that has trace_pipe open on one instance should prevent another instance from changing its current tracer. Move the reference counter to the trace_array instead.
This is marked as "Fixes" but is more of a clean up than a true fix. Backport if you want, but its not critical.
A note to stable maintainers. I originally thought this was just a clean up, but it was then found that it actually does fix a bug. (See below)
-- Steve
Fixes: cf6ab6d9143b1 ("tracing: Add ref count to tracer for when they are being read by pipe") Signed-off-by: Steven Rostedt (VMware) rostedt@goodmis.org Cc: stable@vger.kernel.org # 5.4.x [Resolved conflict in __remove_instance()] Signed-off-by: dann frazier dann.frazier@canonical.com
This addresses an issue we've seen with users trying to change current_tracer when they happen to have rasdaemon installed. rasdaemon uses the trace_pipe interface at runtime, which therefore blocks changing the current tracer. But of course, unless you know about rasdaemon internals, it isn't exactly an obvious failure mode.
Conflict in __remove_instance() was due to a change in reference counter semantics introduced later in v5.5 via commit 288797871473 "tracing: Adding new functions for kernel access to Ftrace instances". Resolved by leaving the first test in the if statement as it was in v5.4.
kernel/trace/trace.c | 12 ++++++------ kernel/trace/trace.h | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-)