diff options
author | Steven Rostedt <srostedt@redhat.com> | 2010-05-14 10:19:13 -0400 |
---|---|---|
committer | Steven Rostedt <rostedt@goodmis.org> | 2010-05-14 21:17:41 -0400 |
commit | 1eaa4787a774c4896518c81f24e8bccaa2244924 (patch) | |
tree | 45c2f0646803d8f77d25c75dcac7bf120eb19507 /kernel/sysctl.c | |
parent | e1f7992e015ae1373d66c8068d0a45e4111a0aed (diff) |
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@efficios.com>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Tom Zanussi <tzanussi@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Diffstat (limited to 'kernel/sysctl.c')
0 files changed, 0 insertions, 0 deletions