lkml.org 
[lkml]   [2010]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 13/13 v3] tracing: Comment the use of event_mutex with trace event flags
* Steven Rostedt (rostedt@goodmis.org) wrote:
> From: Steven Rostedt <srostedt@redhat.com>
>
> 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.
>
> Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Tom Zanussi <tzanussi@gmail.com>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> include/linux/ftrace_event.h | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index 5ac97a4..3578e90 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
> + * cacheing and such.

cacheing -> caching ?

Besides this minor nit:

Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

> */
> unsigned int flags;
>
> --
> 1.7.0
>
>

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com


\
 
 \ /
  Last update: 2010-05-15 00:23    [from the cache]
©2003-2011 Jasper Spaans