linux-kernel - [PATCH][GIT PULL] tracing: Comment the use of event

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: <1273886617.27703.3189.camel@gandalf.stny.rr.com>
Date:	Fri, 14 May 2010 21:23:37 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Tom Zanussi <tzanussi@...il.com>
Subject: [PATCH][GIT PULL] tracing: Comment the use of event_mutex with
 trace event flags


Ingo,

This is the same as the pull request for core-4, but I removed the ring
buffer patch and fixed the typo in the last patch that Mathieu found.

Please pull the latest tip/tracing/core-5 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
tip/tracing/core-5


Steven Rostedt (1):
      tracing: Comment the use of event_mutex with trace event flags

----
 include/linux/ftrace_event.h |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)
---------------------------
commit 1eaa4787a774c4896518c81f24e8bccaa2244924
Author: Steven Rostedt <srostedt@...hat.com>
Date:   Fri May 14 10:19:13 2010 -0400

    tracing: Comment the use of event_mutex with trace event flags
    
    The flags variable is protected by the event_mutex when modifying,
    but the event_mutex is not held when reading the variable.
    
    This is due to the fact that the reads occur in critical sections where
    taking a mutex (or even a spinlock) is not wanted.
    
    But the two flags that exist (enable and filter_active) have the code
    written as such to handle the reads to not need a lock.
    
    The enable flag is used just to know if the event is enabled or not
    and its use is always under the event_mutex. Whether or not the event
    is actually enabled is really determined by the tracepoint being
    registered. The flag is just a way to let the code know if the tracepoint
    is registered.
    
    The filter_active is different. It is read without the lock. If it
    is set, then the event probes jump to the filter code. There can be a
    slight mismatch between filters available and filter_active. If the flag is
    set but no filters are available, the code safely jumps to a filter nop.
    If the flag is not set and the filters are available, then the filters
    are skipped. This is acceptable since filters are usually set before
    tracing or they are set by humans, which would not notice the slight
    delay that this causes.
    
    v2: Fixed typo: "cacheing" -> "caching"
    
    Reported-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
    Acked-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
    Cc: Tom Zanussi <tzanussi@...il.com>
    Signed-off-by: Steven Rostedt <rostedt@...dmis.org>

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 5ac97a4..dc7fc64 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -169,7 +169,14 @@ struct ftrace_event_call {
 	 *   bit 1:		enabled
 	 *   bit 2:		filter_active
 	 *
-	 *  Must hold event_mutex to change.
+	 * Changes to flags must hold the event_mutex.
+	 *
+	 * Note: Reads of flags do not hold the event_mutex since
+	 * they occur in critical sections. But the way flags
+	 * is currently used, these changes do no affect the code
+	 * except that when a change is made, it may have a slight
+	 * delay in propagating the changes to other CPUs due to
+	 * caching and such.
 	 */
 	unsigned int		flags;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/