linux-kernel - Re: [PATCH 13/13 v3] 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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 May 2010 18:21:40 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Tom Zanussi <tzanussi@...il.com>
Subject: Re: [PATCH 13/13 v3] tracing: Comment the use of event_mutex with
	trace event flags

* Steven Rostedt (rostedt@...dmis.org) wrote:
> From: Steven Rostedt <srostedt@...hat.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@...icios.com>
> Cc: Tom Zanussi <tzanussi@...il.com>
> Signed-off-by: Steven Rostedt <rostedt@...dmis.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@...icios.com>

>  	 */
>  	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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/