[lkml]   [2021]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[GIT PULL] tracing: Fix output of top level event "enable" file
Steven Rostedt (VMware) <>


tracing: Fix output of top level event "enable" file

When writing a tool for enabling events in the tracing system,
an anomaly was discovered. The top level event "enable" file would
never show "1" when all events were enabled. The system and event
"enable" files worked as expected. The reason was because the top
level event "enable" file included the "ftrace" tracer events,
which are not controlled by the "enable" file and would cause the
output to be wrong. This appears to have been a bug since it was created.

Please pull the latest trace-v5.11-rc7 tree, which can be found at:


Tag SHA1: 3587b86427167a0380d98a8d744a2beb1fa8a9d6
Head SHA1: 256cfdd6fdf70c6fcf0f7c8ddb0ebd73ce8f3bc9

Steven Rostedt (VMware) (1):
tracing: Do not count ftrace events in top level enable output

kernel/trace/trace_events.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
commit 256cfdd6fdf70c6fcf0f7c8ddb0ebd73ce8f3bc9
Author: Steven Rostedt (VMware) <>
Date: Fri Feb 5 15:40:04 2021 -0500

tracing: Do not count ftrace events in top level enable output

The file /sys/kernel/tracing/events/enable is used to enable all events by
echoing in "1", or disabling all events when echoing in "0". To know if all
events are enabled, disabled, or some are enabled but not all of them,
cating the file should show either "1" (all enabled), "0" (all disabled), or
"X" (some enabled but not all of them). This works the same as the "enable"
files in the individule system directories (like tracing/events/sched/enable).

But when all events are enabled, the top level "enable" file shows "X". The
reason is that its checking the "ftrace" events, which are special events
that only exist for their format files. These include the format for the
function tracer events, that are enabled when the function tracer is
enabled, but not by the "enable" file. The check includes these events,
which will always be disabled, and even though all true events are enabled,
the top level "enable" file will show "X" instead of "1".

To fix this, have the check test the event's flags to see if it has the
"IGNORE_ENABLE" flag set, and if so, not test it.

Fixes: 553552ce1796c ("tracing: Combine event filter_active and enable into single flags field")
Reported-by: "Yordan Karadzhov (VMware)" <>
Signed-off-by: Steven Rostedt (VMware) <>

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index e9d28eeccb7e..d387b774ceeb 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1212,7 +1212,8 @@ system_enable_read(struct file *filp, char __user *ubuf, size_t cnt,
list_for_each_entry(file, &tr->events, list) {
call = file->event_call;
- if (!trace_event_name(call) || !call->class || !call->class->reg)
+ if ((call->flags & TRACE_EVENT_FL_IGNORE_ENABLE) ||
+ !trace_event_name(call) || !call->class || !call->class->reg)

if (system && strcmp(call->class->system, system->name) != 0)
 \ /
  Last update: 2021-02-08 21:39    [W:0.069 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site