[RFC][PATCH 00/13] ftrace: Allow multiple users to pick and choose functions to trace

[Steven Rostedt]

Ingo, et. al.

This is an RFC patch set of the work I did to allow multiple users
to pick and choose which functions they would like to trace without
being affected by other users (well, they are still affected, but
they can choose their own functions).

Since this rewrote a lot of the guts of ftrace's function handling
I broke it up into steps that I can sequentially think about how to
make the conversion. It also helped in understanding the changes that
had to be made.

The end result now has this:

 o The function record list flags item now stores a ref count, and
   we no longer need to have the flags if the records are filtered
   or set for "notrace"

 o Each ftrace_ops has its own set of functions to trace or not trace
   which is used to update the ref counts of the function records
   mentioned above. If the ftrace_ops is not currently active, the
   records are not touched when the filters are changed. If the filters
   are changed while the ftrace_ops is active, it is done in a way
   with RCU to make the updates.

 o If only one ftrace_ops is registered for tracing (actively tracing),
   its handler is called directly from mcount. Unless the ftrace_ops
   was allocated and not a static/global core kernel variable (see below).

 o If more than one ftrace_ops is registered, then a function is called
   that will iterate over the list of registered ftrace_ops, performing
   a check of each of its hashes to know if ftrace_ops handler should
   be called for that function.

 o If a ftrace_ops is allocated and not a static/global core kernel
   variable, it will be forced to use the function that loops through
   the ftrace_ops even if its the only one. This is because that function
   disables preemption when it performs the loop. This is needed, because
   dynamically allocated ftrace_ops must call synchronize_sched() before
   being freed (which is done when the dynamic ftrace_ops has been
   unregistered).

 o A file has been created in the debugfs/tracing directory called
   enabled_functions. This file contains a list of all functions that
   any ftrace_ops has registered, along with each functions ref count.
   This can be used to make sure nothing is tracing.

I'm posting this patch series as an RFC, but I do not expect it to
change much. I still have to put it through more tests even though
I ran several on each set already.

-- Steve

Steven Rostedt (13):
      ftrace: Replace FTRACE_FL_NOTRACE flag with a hash of ignored functions
      ftrace: Use hash instead for FTRACE_FL_FILTER
      ftrace: Create a global_ops to hold the filter and notrace hashes
      ftrace: Separate hash allocation and assignment
      ftrace: Use counters to enable functions to trace
      ftrace: Add enabled_functions file
      ftrace: Add ops parameter to ftrace_startup/shutdown functions
      ftrace: Have global_ops store the functions that are to be traced
      ftrace: Free hash with call_rcu_sched()
      ftrace: Implement separate user function filtering
      ftrace: Allow dynamically allocated function tracers
      ftrace: Modify ftrace_set_filter/notrace to take ops
      ftrace: Add self-tests for multiple function trace users

----
 include/linux/ftrace.h                |   33 +-
 include/linux/kernel.h                |    1 +
 kernel/extable.c                      |    8 +
 kernel/trace/ftrace.c                 |  992 ++++++++++++++++++++++++++++-----
 kernel/trace/trace.h                  |    2 +
 kernel/trace/trace_functions.c        |    2 +
 kernel/trace/trace_irqsoff.c          |    1 +
 kernel/trace/trace_sched_wakeup.c     |    1 +
 kernel/trace/trace_selftest.c         |  214 +++++++-
 kernel/trace/trace_selftest_dynamic.c |    6 +
 kernel/trace/trace_stack.c            |    1 +
 11 files changed, 1116 insertions(+), 145 deletions(-)
--
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/