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    [W:0.027 / U:59.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site