Re: [PATCH 13/13 v3] tracing: Comment the use of event_mutex withtrace event flags

[Mathieu Desnoyers]

* Steven Rostedt (rostedt@xxxxxxxxxxx) wrote:
> From: Steven Rostedt <srostedt@xxxxxxxxxx>
> 
> 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@xxxxxxxxxxxx>
> Cc: Tom Zanussi <tzanussi@xxxxxxxxx>
> Signed-off-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
> ---
>  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@xxxxxxxxxxxx>

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

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/