• Masami Hiramatsu's avatar
    tracing: Lock event_mutex before synth_event_mutex · fc800a10
    Masami Hiramatsu authored
    synthetic event is using synth_event_mutex for protecting
    synth_event_list, and event_trigger_write() path acquires
    locks as below order.
    
    event_trigger_write(event_mutex)
      ->trigger_process_regex(trigger_cmd_mutex)
        ->event_hist_trigger_func(synth_event_mutex)
    
    On the other hand, synthetic event creation and deletion paths
    call trace_add_event_call() and trace_remove_event_call()
    which acquires event_mutex. In that case, if we keep the
    synth_event_mutex locked while registering/unregistering synthetic
    events, its dependency will be inversed.
    
    To avoid this issue, current synthetic event is using a 2 phase
    process to create/delete events. For example, it searches existing
    events under synth_event_mutex to check for event-name conflicts, and
    unlocks synth_event_mutex, then registers a new event under event_mutex
    locked. Finally, it locks synth_event_mutex and tries to add the
    new event to the list. But it can introduce complexity and a chance
    for name conflicts.
    
    To solve this simpler, this introduces trace_add_event_call_nolock()
    and trace_remove_event_call_nolock() which don't acquire
    event_mutex inside. synthetic event can lock event_mutex before
    synth_event_mutex to solve the lock dependency issue simpler.
    
    Link: http://lkml.kernel.org/r/154140844377.17322.13781091165954002713.stgit@devboxReviewed-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
    Tested-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
    Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
    fc800a10
trace_events_hist.c 133 KB