lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20210208105113.2c4598ff@gandalf.local.home>
Date:   Mon, 8 Feb 2021 10:51:13 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Yordan Karadzhov <y.karadz@...il.com>
Subject: [for-linus][PATCH] tracing: Do not count ftrace events in top level
 enable output


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) <rostedt@...dmis.org>
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.
    
    Cc: stable@...r.kernel.org
    Fixes: 553552ce1796c ("tracing: Combine event filter_active and enable into single flags field")
    Reported-by: "Yordan Karadzhov (VMware)" <y.karadz@...il.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>

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,
 	mutex_lock(&event_mutex);
 	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)
 			continue;
 
 		if (system && strcmp(call->class->system, system->name) != 0)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ