2009-03-19 22:26:15 +03:00
/*
* trace event based perf counter profiling
*
* Copyright ( C ) 2009 Red Hat Inc , Peter Zijlstra < pzijlstr @ redhat . com >
*
*/
2009-08-24 08:19:47 +04:00
# include <linux/module.h>
2009-03-19 22:26:15 +03:00
# include "trace.h"
2009-09-18 08:10:28 +04:00
2009-11-22 07:26:55 +03:00
char * perf_trace_buf ;
tracing, perf_events: Protect the buffer from recursion in perf
While tracing using events with perf, if one enables the
lockdep:lock_acquire event, it will infect every other perf
trace events.
Basically, you can enable whatever set of trace events through
perf but if this event is part of the set, the only result we
can get is a long list of lock_acquire events of rcu read lock,
and only that.
This is because of a recursion inside perf.
1) When a trace event is triggered, it will fill a per cpu
buffer and submit it to perf.
2) Perf will commit this event but will also protect some data
using rcu_read_lock
3) A recursion appears: rcu_read_lock triggers a lock_acquire
event that will fill the per cpu event and then submit the
buffer to perf.
4) Perf detects a recursion and ignores it
5) Perf continues its work on the previous event, but its buffer
has been overwritten by the lock_acquire event, it has then
been turned into a lock_acquire event of rcu read lock
Such scenario also happens with lock_release with
rcu_read_unlock().
We could turn the rcu_read_lock() into __rcu_read_lock() to drop
the lock debugging from perf fast path, but that would make us
lose the rcu debugging and that doesn't prevent from other
possible kind of recursion from perf in the future.
This patch adds a recursion protection based on a counter on the
perf trace per cpu buffers to solve the problem.
-v2: Fixed lost whitespace, added reviewed-by tag
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Jason Baron <jbaron@redhat.com>
LKML-Reference: <1257477185-7838-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-06 06:13:05 +03:00
EXPORT_SYMBOL_GPL ( perf_trace_buf ) ;
2009-09-20 14:34:38 +04:00
2009-11-22 07:26:55 +03:00
char * perf_trace_buf_nmi ;
tracing, perf_events: Protect the buffer from recursion in perf
While tracing using events with perf, if one enables the
lockdep:lock_acquire event, it will infect every other perf
trace events.
Basically, you can enable whatever set of trace events through
perf but if this event is part of the set, the only result we
can get is a long list of lock_acquire events of rcu read lock,
and only that.
This is because of a recursion inside perf.
1) When a trace event is triggered, it will fill a per cpu
buffer and submit it to perf.
2) Perf will commit this event but will also protect some data
using rcu_read_lock
3) A recursion appears: rcu_read_lock triggers a lock_acquire
event that will fill the per cpu event and then submit the
buffer to perf.
4) Perf detects a recursion and ignores it
5) Perf continues its work on the previous event, but its buffer
has been overwritten by the lock_acquire event, it has then
been turned into a lock_acquire event of rcu read lock
Such scenario also happens with lock_release with
rcu_read_unlock().
We could turn the rcu_read_lock() into __rcu_read_lock() to drop
the lock debugging from perf fast path, but that would make us
lose the rcu debugging and that doesn't prevent from other
possible kind of recursion from perf in the future.
This patch adds a recursion protection based on a counter on the
perf trace per cpu buffers to solve the problem.
-v2: Fixed lost whitespace, added reviewed-by tag
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Jason Baron <jbaron@redhat.com>
LKML-Reference: <1257477185-7838-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-06 06:13:05 +03:00
EXPORT_SYMBOL_GPL ( perf_trace_buf_nmi ) ;
2009-09-18 08:10:28 +04:00
2009-11-22 07:26:55 +03:00
typedef typeof ( char [ FTRACE_MAX_PROFILE_SIZE ] ) perf_trace_t ;
2009-09-18 08:10:28 +04:00
/* Count the events in use (per event id, not per instance) */
static int total_profile_count ;
2009-09-18 02:54:43 +04:00
static int ftrace_profile_enable_event ( struct ftrace_event_call * event )
{
2009-11-22 07:26:55 +03:00
char * buf ;
2009-09-18 08:10:28 +04:00
int ret = - ENOMEM ;
2009-09-18 02:54:43 +04:00
if ( atomic_inc_return ( & event - > profile_count ) )
return 0 ;
2009-10-03 16:55:18 +04:00
if ( ! total_profile_count ) {
2009-11-22 07:26:55 +03:00
buf = ( char * ) alloc_percpu ( perf_trace_t ) ;
2009-09-18 08:10:28 +04:00
if ( ! buf )
goto fail_buf ;
tracing, perf_events: Protect the buffer from recursion in perf
While tracing using events with perf, if one enables the
lockdep:lock_acquire event, it will infect every other perf
trace events.
Basically, you can enable whatever set of trace events through
perf but if this event is part of the set, the only result we
can get is a long list of lock_acquire events of rcu read lock,
and only that.
This is because of a recursion inside perf.
1) When a trace event is triggered, it will fill a per cpu
buffer and submit it to perf.
2) Perf will commit this event but will also protect some data
using rcu_read_lock
3) A recursion appears: rcu_read_lock triggers a lock_acquire
event that will fill the per cpu event and then submit the
buffer to perf.
4) Perf detects a recursion and ignores it
5) Perf continues its work on the previous event, but its buffer
has been overwritten by the lock_acquire event, it has then
been turned into a lock_acquire event of rcu read lock
Such scenario also happens with lock_release with
rcu_read_unlock().
We could turn the rcu_read_lock() into __rcu_read_lock() to drop
the lock debugging from perf fast path, but that would make us
lose the rcu debugging and that doesn't prevent from other
possible kind of recursion from perf in the future.
This patch adds a recursion protection based on a counter on the
perf trace per cpu buffers to solve the problem.
-v2: Fixed lost whitespace, added reviewed-by tag
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Jason Baron <jbaron@redhat.com>
LKML-Reference: <1257477185-7838-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-06 06:13:05 +03:00
rcu_assign_pointer ( perf_trace_buf , buf ) ;
2009-09-18 08:10:28 +04:00
2009-11-22 07:26:55 +03:00
buf = ( char * ) alloc_percpu ( perf_trace_t ) ;
2009-09-18 08:10:28 +04:00
if ( ! buf )
goto fail_buf_nmi ;
tracing, perf_events: Protect the buffer from recursion in perf
While tracing using events with perf, if one enables the
lockdep:lock_acquire event, it will infect every other perf
trace events.
Basically, you can enable whatever set of trace events through
perf but if this event is part of the set, the only result we
can get is a long list of lock_acquire events of rcu read lock,
and only that.
This is because of a recursion inside perf.
1) When a trace event is triggered, it will fill a per cpu
buffer and submit it to perf.
2) Perf will commit this event but will also protect some data
using rcu_read_lock
3) A recursion appears: rcu_read_lock triggers a lock_acquire
event that will fill the per cpu event and then submit the
buffer to perf.
4) Perf detects a recursion and ignores it
5) Perf continues its work on the previous event, but its buffer
has been overwritten by the lock_acquire event, it has then
been turned into a lock_acquire event of rcu read lock
Such scenario also happens with lock_release with
rcu_read_unlock().
We could turn the rcu_read_lock() into __rcu_read_lock() to drop
the lock debugging from perf fast path, but that would make us
lose the rcu debugging and that doesn't prevent from other
possible kind of recursion from perf in the future.
This patch adds a recursion protection based on a counter on the
perf trace per cpu buffers to solve the problem.
-v2: Fixed lost whitespace, added reviewed-by tag
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Jason Baron <jbaron@redhat.com>
LKML-Reference: <1257477185-7838-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-06 06:13:05 +03:00
rcu_assign_pointer ( perf_trace_buf_nmi , buf ) ;
2009-09-18 08:10:28 +04:00
}
2009-09-24 01:08:43 +04:00
ret = event - > profile_enable ( event ) ;
2009-10-03 16:55:18 +04:00
if ( ! ret ) {
total_profile_count + + ;
2009-09-18 08:10:28 +04:00
return 0 ;
2009-10-03 16:55:18 +04:00
}
2009-09-18 08:10:28 +04:00
fail_buf_nmi :
2009-10-03 16:55:18 +04:00
if ( ! total_profile_count ) {
tracing, perf_events: Protect the buffer from recursion in perf
While tracing using events with perf, if one enables the
lockdep:lock_acquire event, it will infect every other perf
trace events.
Basically, you can enable whatever set of trace events through
perf but if this event is part of the set, the only result we
can get is a long list of lock_acquire events of rcu read lock,
and only that.
This is because of a recursion inside perf.
1) When a trace event is triggered, it will fill a per cpu
buffer and submit it to perf.
2) Perf will commit this event but will also protect some data
using rcu_read_lock
3) A recursion appears: rcu_read_lock triggers a lock_acquire
event that will fill the per cpu event and then submit the
buffer to perf.
4) Perf detects a recursion and ignores it
5) Perf continues its work on the previous event, but its buffer
has been overwritten by the lock_acquire event, it has then
been turned into a lock_acquire event of rcu read lock
Such scenario also happens with lock_release with
rcu_read_unlock().
We could turn the rcu_read_lock() into __rcu_read_lock() to drop
the lock debugging from perf fast path, but that would make us
lose the rcu debugging and that doesn't prevent from other
possible kind of recursion from perf in the future.
This patch adds a recursion protection based on a counter on the
perf trace per cpu buffers to solve the problem.
-v2: Fixed lost whitespace, added reviewed-by tag
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Jason Baron <jbaron@redhat.com>
LKML-Reference: <1257477185-7838-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-06 06:13:05 +03:00
free_percpu ( perf_trace_buf_nmi ) ;
free_percpu ( perf_trace_buf ) ;
perf_trace_buf_nmi = NULL ;
perf_trace_buf = NULL ;
2009-10-03 16:55:18 +04:00
}
2009-09-18 08:10:28 +04:00
fail_buf :
atomic_dec ( & event - > profile_count ) ;
return ret ;
2009-09-18 02:54:43 +04:00
}
2009-03-19 22:26:15 +03:00
int ftrace_profile_enable ( int event_id )
{
struct ftrace_event_call * event ;
2009-05-06 06:33:45 +04:00
int ret = - EINVAL ;
2009-03-19 22:26:15 +03:00
2009-05-06 06:33:45 +04:00
mutex_lock ( & event_mutex ) ;
2009-04-10 21:52:20 +04:00
list_for_each_entry ( event , & ftrace_events , list ) {
2009-08-24 08:19:47 +04:00
if ( event - > id = = event_id & & event - > profile_enable & &
try_module_get ( event - > mod ) ) {
2009-09-18 02:54:43 +04:00
ret = ftrace_profile_enable_event ( event ) ;
2009-05-06 06:33:45 +04:00
break ;
}
2009-03-19 22:26:15 +03:00
}
2009-05-06 06:33:45 +04:00
mutex_unlock ( & event_mutex ) ;
2009-03-19 22:26:15 +03:00
2009-05-06 06:33:45 +04:00
return ret ;
2009-03-19 22:26:15 +03:00
}
2009-09-18 02:54:43 +04:00
static void ftrace_profile_disable_event ( struct ftrace_event_call * event )
{
2009-11-22 07:26:55 +03:00
char * buf , * nmi_buf ;
2009-09-18 08:10:28 +04:00
2009-09-18 02:54:43 +04:00
if ( ! atomic_add_negative ( - 1 , & event - > profile_count ) )
return ;
2009-09-24 01:08:43 +04:00
event - > profile_disable ( event ) ;
2009-09-18 08:10:28 +04:00
if ( ! - - total_profile_count ) {
tracing, perf_events: Protect the buffer from recursion in perf
While tracing using events with perf, if one enables the
lockdep:lock_acquire event, it will infect every other perf
trace events.
Basically, you can enable whatever set of trace events through
perf but if this event is part of the set, the only result we
can get is a long list of lock_acquire events of rcu read lock,
and only that.
This is because of a recursion inside perf.
1) When a trace event is triggered, it will fill a per cpu
buffer and submit it to perf.
2) Perf will commit this event but will also protect some data
using rcu_read_lock
3) A recursion appears: rcu_read_lock triggers a lock_acquire
event that will fill the per cpu event and then submit the
buffer to perf.
4) Perf detects a recursion and ignores it
5) Perf continues its work on the previous event, but its buffer
has been overwritten by the lock_acquire event, it has then
been turned into a lock_acquire event of rcu read lock
Such scenario also happens with lock_release with
rcu_read_unlock().
We could turn the rcu_read_lock() into __rcu_read_lock() to drop
the lock debugging from perf fast path, but that would make us
lose the rcu debugging and that doesn't prevent from other
possible kind of recursion from perf in the future.
This patch adds a recursion protection based on a counter on the
perf trace per cpu buffers to solve the problem.
-v2: Fixed lost whitespace, added reviewed-by tag
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Jason Baron <jbaron@redhat.com>
LKML-Reference: <1257477185-7838-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-06 06:13:05 +03:00
buf = perf_trace_buf ;
rcu_assign_pointer ( perf_trace_buf , NULL ) ;
2009-09-18 08:10:28 +04:00
tracing, perf_events: Protect the buffer from recursion in perf
While tracing using events with perf, if one enables the
lockdep:lock_acquire event, it will infect every other perf
trace events.
Basically, you can enable whatever set of trace events through
perf but if this event is part of the set, the only result we
can get is a long list of lock_acquire events of rcu read lock,
and only that.
This is because of a recursion inside perf.
1) When a trace event is triggered, it will fill a per cpu
buffer and submit it to perf.
2) Perf will commit this event but will also protect some data
using rcu_read_lock
3) A recursion appears: rcu_read_lock triggers a lock_acquire
event that will fill the per cpu event and then submit the
buffer to perf.
4) Perf detects a recursion and ignores it
5) Perf continues its work on the previous event, but its buffer
has been overwritten by the lock_acquire event, it has then
been turned into a lock_acquire event of rcu read lock
Such scenario also happens with lock_release with
rcu_read_unlock().
We could turn the rcu_read_lock() into __rcu_read_lock() to drop
the lock debugging from perf fast path, but that would make us
lose the rcu debugging and that doesn't prevent from other
possible kind of recursion from perf in the future.
This patch adds a recursion protection based on a counter on the
perf trace per cpu buffers to solve the problem.
-v2: Fixed lost whitespace, added reviewed-by tag
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Jason Baron <jbaron@redhat.com>
LKML-Reference: <1257477185-7838-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-06 06:13:05 +03:00
nmi_buf = perf_trace_buf_nmi ;
rcu_assign_pointer ( perf_trace_buf_nmi , NULL ) ;
2009-09-18 08:10:28 +04:00
/*
* Ensure every events in profiling have finished before
* releasing the buffers
*/
synchronize_sched ( ) ;
free_percpu ( buf ) ;
free_percpu ( nmi_buf ) ;
}
2009-09-18 02:54:43 +04:00
}
2009-03-19 22:26:15 +03:00
void ftrace_profile_disable ( int event_id )
{
struct ftrace_event_call * event ;
2009-05-06 06:33:45 +04:00
mutex_lock ( & event_mutex ) ;
2009-04-10 21:52:20 +04:00
list_for_each_entry ( event , & ftrace_events , list ) {
2009-05-06 06:33:45 +04:00
if ( event - > id = = event_id ) {
2009-09-18 02:54:43 +04:00
ftrace_profile_disable_event ( event ) ;
2009-08-24 08:19:47 +04:00
module_put ( event - > mod ) ;
2009-05-06 06:33:45 +04:00
break ;
}
2009-03-19 22:26:15 +03:00
}
2009-05-06 06:33:45 +04:00
mutex_unlock ( & event_mutex ) ;
2009-03-19 22:26:15 +03:00
}