1. 11 4月, 2017 1 次提交
  2. 09 12月, 2016 1 次提交
    • S
      tracing: Have the reg function allow to fail · 8cf868af
      Steven Rostedt (Red Hat) 提交于
      Some tracepoints have a registration function that gets enabled when the
      tracepoint is enabled. There may be cases that the registraction function
      must fail (for example, can't allocate enough memory). In this case, the
      tracepoint should also fail to register, otherwise the user would not know
      why the tracepoint is not working.
      
      Cc: David Howells <dhowells@redhat.com>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      8cf868af
  3. 10 3月, 2016 1 次提交
    • S
      tracing: Fix check for cpu online when event is disabled · dc17147d
      Steven Rostedt (Red Hat) 提交于
      Commit f3775549 ("tracepoints: Do not trace when cpu is offline") added
      a check to make sure that tracepoints only get called when the cpu is
      online, as it uses rcu_read_lock_sched() for protection.
      
      Commit 3a630178 ("tracing: generate RCU warnings even when tracepoints
      are disabled") added lockdep checks (including rcu checks) for events that
      are not enabled to catch possible RCU issues that would only be triggered if
      a trace event was enabled. Commit f3775549 only stopped the warnings
      when the trace event was enabled but did not prevent warnings if the trace
      event was called when disabled.
      
      To fix this, the cpu online check is moved to where the condition is added
      to the trace event. This will place the cpu online check in all places that
      it may be used now and in the future.
      
      Cc: stable@vger.kernel.org # v3.18+
      Fixes: f3775549 ("tracepoints: Do not trace when cpu is offline")
      Fixes: 3a630178 ("tracing: generate RCU warnings even when tracepoints are disabled")
      Reported-by: NSudeep Holla <sudeep.holla@arm.com>
      Tested-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      dc17147d
  4. 16 2月, 2016 1 次提交
    • S
      tracepoints: Do not trace when cpu is offline · f3775549
      Steven Rostedt (Red Hat) 提交于
      The tracepoint infrastructure uses RCU sched protection to enable and
      disable tracepoints safely. There are some instances where tracepoints are
      used in infrastructure code (like kfree()) that get called after a CPU is
      going offline, and perhaps when it is coming back online but hasn't been
      registered yet.
      
      This can probuce the following warning:
      
       [ INFO: suspicious RCU usage. ]
       4.4.0-00006-g0fe53e8-dirty #34 Tainted: G S
       -------------------------------
       include/trace/events/kmem.h:141 suspicious rcu_dereference_check() usage!
      
       other info that might help us debug this:
      
       RCU used illegally from offline CPU!  rcu_scheduler_active = 1, debug_locks = 1
       no locks held by swapper/8/0.
      
       stack backtrace:
        CPU: 8 PID: 0 Comm: swapper/8 Tainted: G S              4.4.0-00006-g0fe53e8-dirty #34
        Call Trace:
        [c0000005b76c78d0] [c0000000008b9540] .dump_stack+0x98/0xd4 (unreliable)
        [c0000005b76c7950] [c00000000010c898] .lockdep_rcu_suspicious+0x108/0x170
        [c0000005b76c79e0] [c00000000029adc0] .kfree+0x390/0x440
        [c0000005b76c7a80] [c000000000055f74] .destroy_context+0x44/0x100
        [c0000005b76c7b00] [c0000000000934a0] .__mmdrop+0x60/0x150
        [c0000005b76c7b90] [c0000000000e3ff0] .idle_task_exit+0x130/0x140
        [c0000005b76c7c20] [c000000000075804] .pseries_mach_cpu_die+0x64/0x310
        [c0000005b76c7cd0] [c000000000043e7c] .cpu_die+0x3c/0x60
        [c0000005b76c7d40] [c0000000000188d8] .arch_cpu_idle_dead+0x28/0x40
        [c0000005b76c7db0] [c000000000101e6c] .cpu_startup_entry+0x50c/0x560
        [c0000005b76c7ed0] [c000000000043bd8] .start_secondary+0x328/0x360
        [c0000005b76c7f90] [c000000000008a6c] start_secondary_prolog+0x10/0x14
      
      This warning is not a false positive either. RCU is not protecting code that
      is being executed while the CPU is offline.
      
      Instead of playing "whack-a-mole(TM)" and adding conditional statements to
      the tracepoints we find that are used in this instance, simply add a
      cpu_online() test to the tracepoint code where the tracepoint will be
      ignored if the CPU is offline.
      
      Use of raw_smp_processor_id() is fine, as there should never be a case where
      the tracepoint code goes from running on a CPU that is online and suddenly
      gets migrated to a CPU that is offline.
      
      Link: http://lkml.kernel.org/r/1455387773-4245-1-git-send-email-kda@linux-powerpc.orgReported-by: NDenis Kirjanov <kda@linux-powerpc.org>
      Fixes: 97e1c18e ("tracing: Kernel Tracepoints")
      Cc: stable@vger.kernel.org # v2.6.28+
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      f3775549
  5. 24 12月, 2015 1 次提交
  6. 08 12月, 2015 1 次提交
    • P
      rcu: Don't redundantly disable irqs in rcu_irq_{enter,exit}() · 7c9906ca
      Paul E. McKenney 提交于
      This commit replaces a local_irq_save()/local_irq_restore() pair with
      a lockdep assertion that interrupts are already disabled.  This should
      remove the corresponding overhead from the interrupt entry/exit fastpaths.
      
      This change was inspired by the fact that Iftekhar Ahmed's mutation
      testing showed that removing rcu_irq_enter()'s call to local_ird_restore()
      had no effect, which might indicate that interrupts were always enabled
      anyway.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      7c9906ca
  7. 06 12月, 2015 1 次提交
  8. 03 11月, 2015 1 次提交
  9. 26 10月, 2015 1 次提交
    • S
      tracepoint: Give priority to probes of tracepoints · 7904b5c4
      Steven Rostedt (Red Hat) 提交于
      In order to guarantee that a probe will be called before other probes that
      are attached to a tracepoint, there needs to be a mechanism to provide
      priority of one probe over the others.
      
      Adding a prio field to the struct tracepoint_func, which lets the probes be
      sorted by the priority set in the structure. If no priority is specified,
      then a priority of 10 is given (this is a macro, and perhaps may be changed
      in the future).
      
      Now probes may be added to affect other probes that are attached to a
      tracepoint with a guaranteed order.
      
      One use case would be to allow tracing of tracepoints be able to filter by
      pid. A special (higher priority probe) may be added to the sched_switch
      tracepoint and set the necessary flags of the other tracepoints to notify
      them if they should be traced or not. In case a tracepoint is enabled at the
      sched_switch tracepoint too, the order of the two are not random.
      
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      7904b5c4
  10. 21 10月, 2015 1 次提交
  11. 08 4月, 2015 1 次提交
    • S
      tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values · 0c564a53
      Steven Rostedt (Red Hat) 提交于
      Several tracepoints use the helper functions __print_symbolic() or
      __print_flags() and pass in enums that do the mapping between the
      binary data stored and the value to print. This works well for reading
      the ASCII trace files, but when the data is read via userspace tools
      such as perf and trace-cmd, the conversion of the binary value to a
      human string format is lost if an enum is used, as userspace does not
      have access to what the ENUM is.
      
      For example, the tracepoint trace_tlb_flush() has:
      
       __print_symbolic(REC->reason,
          { TLB_FLUSH_ON_TASK_SWITCH, "flush on task switch" },
          { TLB_REMOTE_SHOOTDOWN, "remote shootdown" },
          { TLB_LOCAL_SHOOTDOWN, "local shootdown" },
          { TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" })
      
      Which maps the enum values to the strings they represent. But perf and
      trace-cmd do no know what value TLB_LOCAL_MM_SHOOTDOWN is, and would
      not be able to map it.
      
      With TRACE_DEFINE_ENUM(), developers can place these in the event header
      files and ftrace will convert the enums to their values:
      
      By adding:
      
       TRACE_DEFINE_ENUM(TLB_FLUSH_ON_TASK_SWITCH);
       TRACE_DEFINE_ENUM(TLB_REMOTE_SHOOTDOWN);
       TRACE_DEFINE_ENUM(TLB_LOCAL_SHOOTDOWN);
       TRACE_DEFINE_ENUM(TLB_LOCAL_MM_SHOOTDOWN);
      
       $ cat /sys/kernel/debug/tracing/events/tlb/tlb_flush/format
      [...]
       __print_symbolic(REC->reason,
          { 0, "flush on task switch" },
          { 1, "remote shootdown" },
          { 2, "local shootdown" },
          { 3, "local mm shootdown" })
      
      The above is what userspace expects to see, and tools do not need to
      be modified to parse them.
      
      Link: http://lkml.kernel.org/r/20150403013802.220157513@goodmis.org
      
      Cc: Guilherme Cox <cox@computer.org>
      Cc: Tony Luck <tony.luck@gmail.com>
      Cc: Xie XiuQi <xiexiuqi@huawei.com>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Reviewed-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Tested-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      0c564a53
  12. 08 2月, 2015 1 次提交
  13. 10 9月, 2014 1 次提交
  14. 08 8月, 2014 1 次提交
  15. 08 5月, 2014 1 次提交
    • S
      tracing: Add trace_<tracepoint>_enabled() function · 7c65bbc7
      Steven Rostedt (Red Hat) 提交于
      There are some code paths in the kernel that need to do some preparations
      before it calls a tracepoint. As that code is worthless overhead when
      the tracepoint is not enabled, it would be prudent to have that code
      only run when the tracepoint is active. To accomplish this, all tracepoints
      now get a static inline function called "trace_<tracepoint-name>_enabled()"
      which returns true when the tracepoint is enabled and false otherwise.
      
      As an added bonus, that function uses the static_key of the tracepoint
      such that no branch is needed.
      
        if (trace_mytracepoint_enabled()) {
      	arg = process_tp_arg();
      	trace_mytracepoint(arg);
        }
      
      Will keep the "process_tp_arg()" (which may be expensive to run) from
      being executed when the tracepoint isn't enabled.
      
      It's best to encapsulate the tracepoint itself in the if statement
      just to keep races. For example, if you had:
      
        if (trace_mytracepoint_enabled())
      	arg = process_tp_arg();
        trace_mytracepoint(arg);
      
      There's a chance that the tracepoint could be enabled just after the
      if statement, and arg will be undefined when calling the tracepoint.
      
      Link: http://lkml.kernel.org/r/20140506094407.507b6435@gandalf.local.homeAcked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      7c65bbc7
  16. 09 4月, 2014 3 次提交
  17. 22 3月, 2014 1 次提交
  18. 04 3月, 2014 1 次提交
  19. 02 12月, 2013 1 次提交
  20. 19 11月, 2013 1 次提交
  21. 21 6月, 2013 1 次提交
    • S
      tracing: Add DEFINE_EVENT_FN() macro · f5abaa1b
      Steven Rostedt 提交于
      Each TRACE_EVENT() adds several helper functions. If two or more trace events
      share the same structure and print format, they can also share most of these
      helper functions and save a lot of space from duplicate code. This is why the
      DECLARE_EVENT_CLASS() and DEFINE_EVENT() were created.
      
      Some events require a trigger to be called at registering and unregistering of
      the event and to do so they use TRACE_EVENT_FN().
      
      If multiple events require a trigger, they currently have no choice but to use
      TRACE_EVENT_FN() as there's no DEFINE_EVENT_FN() available. This unfortunately
      causes a lot of wasted duplicate code created.
      
      By adding a DEFINE_EVENT_FN(), these events can still use a
      DECLARE_EVENT_CLASS() and then define their own triggers.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/51C3236C.8030508@hds.comSigned-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      f5abaa1b
  22. 11 6月, 2013 1 次提交
    • P
      trace: Allow idle-safe tracepoints to be called from irq · d6284099
      Paul E. McKenney 提交于
      __DECLARE_TRACE_RCU() currently creates an _rcuidle() tracepoint which
      may safely be invoked from what RCU considers to be an idle CPU.
      However, these _rcuidle() tracepoints may -not- be invoked from the
      handler of an irq taken from idle, because rcu_idle_enter() zeroes
      RCU's nesting-level counter, so that the rcu_irq_exit() returning to
      idle will trigger a WARN_ON_ONCE().
      
      This commit therefore substitutes rcu_irq_enter() for rcu_idle_exit()
      and rcu_irq_exit() for rcu_idle_enter() in order to make the _rcuidle()
      tracepoints usable from irq handlers as well as from process context.
      Reported-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      d6284099
  23. 12 9月, 2012 1 次提交
  24. 06 7月, 2012 1 次提交
  25. 24 2月, 2012 1 次提交
    • I
      static keys: Introduce 'struct static_key', static_key_true()/false() and... · c5905afb
      Ingo Molnar 提交于
      static keys: Introduce 'struct static_key', static_key_true()/false() and static_key_slow_[inc|dec]()
      
      So here's a boot tested patch on top of Jason's series that does
      all the cleanups I talked about and turns jump labels into a
      more intuitive to use facility. It should also address the
      various misconceptions and confusions that surround jump labels.
      
      Typical usage scenarios:
      
              #include <linux/static_key.h>
      
              struct static_key key = STATIC_KEY_INIT_TRUE;
      
              if (static_key_false(&key))
                      do unlikely code
              else
                      do likely code
      
      Or:
      
              if (static_key_true(&key))
                      do likely code
              else
                      do unlikely code
      
      The static key is modified via:
      
              static_key_slow_inc(&key);
              ...
              static_key_slow_dec(&key);
      
      The 'slow' prefix makes it abundantly clear that this is an
      expensive operation.
      
      I've updated all in-kernel code to use this everywhere. Note
      that I (intentionally) have not pushed through the rename
      blindly through to the lowest levels: the actual jump-label
      patching arch facility should be named like that, so we want to
      decouple jump labels from the static-key facility a bit.
      
      On non-jump-label enabled architectures static keys default to
      likely()/unlikely() branches.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NJason Baron <jbaron@redhat.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: a.p.zijlstra@chello.nl
      Cc: mathieu.desnoyers@efficios.com
      Cc: davem@davemloft.net
      Cc: ddaney.cavm@gmail.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20120222085809.GA26397@elte.huSigned-off-by: NIngo Molnar <mingo@elte.hu>
      c5905afb
  26. 13 2月, 2012 1 次提交
    • S
      tracing/rcu: Add trace_##name##__rcuidle() static tracepoint for inside rcu_idle_exit() sections · 2fbb90db
      Steven Rostedt 提交于
      Added is a new static inline function that lets *any* tracepoint be used
      inside a rcu_idle_exit() section. And this also solves the problem where
      the same tracepoint may be used inside a rcu_idle_exit() section as well
      as outside of one.
      
      I added a new tracepoint function with a "_rcuidle" extension. All
      tracepoints can be used with either the normal "trace_foobar()"
      function, or the "trace_foobar_rcuidle()" function when inside a
      rcu_idle_exit() section.
      
      All tracepoints defined by TRACE_EVENT() or any of the derivatives
      will have a "_rcuidle()" function also defined. When a tracepoint is
      used within an rcu_idle_exit() section, the "_rcuidle()" version must
      be used. This denotes that the tracepoint is within rcu_idle_exit()
      and it allows the rcu read locks within the tracepoint to still
      be valid, as this version takes us out of rcu_idle_exit().
      
      Another nice aspect about this patch is that "static inline"s are not
      compiled into text when not used. So only the tracepoints that actually
      use the _rcuidle() version will have them defined in the actual text
      that is booted.
      
      Link: http://lkml.kernel.org/r/1328563113.2200.39.camel@gandalf.stny.rr.com>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      2fbb90db
  27. 11 8月, 2011 1 次提交
    • M
      Tracepoint: Dissociate from module mutex · b75ef8b4
      Mathieu Desnoyers 提交于
      Copy the information needed from struct module into a local module list
      held within tracepoint.c from within the module coming/going notifier.
      
      This vastly simplifies locking of tracepoint registration /
      unregistration, because we don't have to take the module mutex to
      register and unregister tracepoints anymore. Steven Rostedt ran into
      dependency problems related to modules mutex vs kprobes mutex vs ftrace
      mutex vs tracepoint mutex that seems to be hard to fix without removing
      this dependency between tracepoint and module mutex. (note: it should be
      investigated whether kprobes could benefit of being dissociated from the
      modules mutex too.)
      
      This also fixes module handling of tracepoint list iterators, because it
      was expecting the list to be sorted by pointer address. Given we have
      control on our own list now, it's OK to sort this list which has
      tracepoints as its only purpose. The reason why this sorting is required
      is to handle the fact that seq files (and any read() operation from
      user-space) cannot hold the tracepoint mutex across multiple calls, so
      list entries may vanish between calls. With sorting, the tracepoint
      iterator becomes usable even if the list don't contain the exact item
      pointed to by the iterator anymore.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NJason Baron <jbaron@redhat.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Lai Jiangshan <laijs@cn.fujitsu.com>
      CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Link: http://lkml.kernel.org/r/20110810191839.GC8525@KrystalSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
      b75ef8b4
  28. 05 4月, 2011 1 次提交
    • J
      jump label: Introduce static_branch() interface · d430d3d7
      Jason Baron 提交于
      Introduce:
      
      static __always_inline bool static_branch(struct jump_label_key *key);
      
      instead of the old JUMP_LABEL(key, label) macro.
      
      In this way, jump labels become really easy to use:
      
      Define:
      
              struct jump_label_key jump_key;
      
      Can be used as:
      
              if (static_branch(&jump_key))
                      do unlikely code
      
      enable/disale via:
      
              jump_label_inc(&jump_key);
              jump_label_dec(&jump_key);
      
      that's it!
      
      For the jump labels disabled case, the static_branch() becomes an
      atomic_read(), and jump_label_inc()/dec() are simply atomic_inc(),
      atomic_dec() operations. We show testing results for this change below.
      
      Thanks to H. Peter Anvin for suggesting the 'static_branch()' construct.
      
      Since we now require a 'struct jump_label_key *key', we can store a pointer into
      the jump table addresses. In this way, we can enable/disable jump labels, in
      basically constant time. This change allows us to completely remove the previous
      hashtable scheme. Thanks to Peter Zijlstra for this re-write.
      
      Testing:
      
      I ran a series of 'tbench 20' runs 5 times (with reboots) for 3
      configurations, where tracepoints were disabled.
      
      jump label configured in
      avg: 815.6
      
      jump label *not* configured in (using atomic reads)
      avg: 800.1
      
      jump label *not* configured in (regular reads)
      avg: 803.4
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <20110316212947.GA8792@redhat.com>
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Suggested-by: NH. Peter Anvin <hpa@linux.intel.com>
      Tested-by: NDavid Daney <ddaney@caviumnetworks.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      d430d3d7
  29. 03 2月, 2011 1 次提交
    • M
      tracepoints: Fix section alignment using pointer array · 65498646
      Mathieu Desnoyers 提交于
      Make the tracepoints more robust, making them solid enough to handle compiler
      changes by not relying on anything based on compiler-specific behavior with
      respect to structure alignment. Implement an approach proposed by David Miller:
      use an array of const pointers to refer to the individual structures, and export
      this pointer array through the linker script rather than the structures per se.
      It will consume 32 extra bytes per tracepoint (24 for structure padding and 8
      for the pointers), but are less likely to break due to compiler changes.
      
      History:
      
      commit 7e066fb8 tracepoints: add DECLARE_TRACE() and DEFINE_TRACE()
      added the aligned(32) type and variable attribute to the tracepoint structures
      to deal with gcc happily aligning statically defined structures on 32-byte
      multiples.
      
      One attempt was to use a 8-byte alignment for tracepoint structures by applying
      both the variable and type attribute to tracepoint structures definitions and
      declarations. It worked fine with gcc 4.5.1, but broke with gcc 4.4.4 and 4.4.5.
      
      The reason is that the "aligned" attribute only specify the _minimum_ alignment
      for a structure, leaving both the compiler and the linker free to align on
      larger multiples. Because tracepoint.c expects the structures to be placed as an
      array within each section, up-alignment cause NULL-pointer exceptions due to the
      extra unexpected padding.
      
      (this patch applies on top of -tip)
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      LKML-Reference: <20110126222622.GA10794@Krystal>
      CC: Frederic Weisbecker <fweisbec@gmail.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Peter Zijlstra <peterz@infradead.org>
      CC: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      65498646
  30. 08 1月, 2011 2 次提交
  31. 03 12月, 2010 1 次提交
    • S
      tracing: Add TRACE_EVENT_CONDITIONAL() · 287050d3
      Steven Rostedt 提交于
      There are instances in the kernel that we only want to trace
      a tracepoint when a certain condition is set. But we do not
      want to test for that condition in the core kernel.
      If we test for that condition before calling the tracepoin, then
      we will be performing that test even when tracing is not enabled.
      This is 99.99% of the time.
      
      We currently can just filter out on that condition, but that happens
      after we write to the trace buffer. We just wasted time writing to
      the ring buffer for an event we never cared about.
      
      This patch adds:
      
         TRACE_EVENT_CONDITION() and DEFINE_EVENT_CONDITION()
      
      These have a new TP_CONDITION() argument that comes right after
      the TP_ARGS().  This condition can use the parameters of TP_ARGS()
      in the TRACE_EVENT() to determine if the tracepoint should be traced
      or not. The TP_CONDITION() will be placed in a if (cond) trace;
      
      For example, for the tracepoint sched_wakeup, it is useless to
      trace a wakeup event where the caller never actually wakes
      anything up (where success == 0). So adding:
      
      	TP_CONDITION(success),
      
      which uses the "success" parameter of the wakeup tracepoint
      will have it only trace when we have successfully woken up a
      task.
      Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      287050d3
  32. 18 11月, 2010 1 次提交
    • F
      tracing: New macro to set up initial event flags value · 1ed0c597
      Frederic Weisbecker 提交于
      This introduces the new TRACE_EVENT_FLAGS() macro in order
      to set up initial event flags value.
      
      This macro must simply follow the definition of a trace event
      and take the event name and the flag value as parameters:
      
      TRACE_EVENT(my_event, .....
      ....
      );
      
      TRACE_EVENT_FLAGS(my_event, 1)
      
      This will set up 1 as the initial my_event->flags value.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Jason Baron <jbaron@redhat.com>
      1ed0c597
  33. 23 9月, 2010 1 次提交
  34. 22 6月, 2010 1 次提交
  35. 14 5月, 2010 2 次提交
    • S
      tracing: Let tracepoints have data passed to tracepoint callbacks · 38516ab5
      Steven Rostedt 提交于
      This patch adds data to be passed to tracepoint callbacks.
      
      The created functions from DECLARE_TRACE() now need a mandatory data
      parameter. For example:
      
      DECLARE_TRACE(mytracepoint, int value, value)
      
      Will create the register function:
      
      int register_trace_mytracepoint((void(*)(void *data, int value))probe,
                                      void *data);
      
      As the first argument, all callbacks (probes) must take a (void *data)
      parameter. So a callback for the above tracepoint will look like:
      
      void myprobe(void *data, int value)
      {
      }
      
      The callback may choose to ignore the data parameter.
      
      This change allows callbacks to register a private data pointer along
      with the function probe.
      
      	void mycallback(void *data, int value);
      
      	register_trace_mytracepoint(mycallback, mydata);
      
      Then the mycallback() will receive the "mydata" as the first parameter
      before the args.
      
      A more detailed example:
      
        DECLARE_TRACE(mytracepoint, TP_PROTO(int status), TP_ARGS(status));
      
        /* In the C file */
      
        DEFINE_TRACE(mytracepoint, TP_PROTO(int status), TP_ARGS(status));
      
        [...]
      
             trace_mytracepoint(status);
      
        /* In a file registering this tracepoint */
      
        int my_callback(void *data, int status)
        {
      	struct my_struct my_data = data;
      	[...]
        }
      
        [...]
      	my_data = kmalloc(sizeof(*my_data), GFP_KERNEL);
      	init_my_data(my_data);
      	register_trace_mytracepoint(my_callback, my_data);
      
      The same callback can also be registered to the same tracepoint as long
      as the data registered is different. Note, the data must also be used
      to unregister the callback:
      
      	unregister_trace_mytracepoint(my_callback, my_data);
      
      Because of the data parameter, tracepoints declared this way can not have
      no args. That is:
      
        DECLARE_TRACE(mytracepoint, TP_PROTO(void), TP_ARGS());
      
      will cause an error.
      
      If no arguments are needed, a new macro can be used instead:
      
        DECLARE_TRACE_NOARGS(mytracepoint);
      
      Since there are no arguments, the proto and args fields are left out.
      
      This is part of a series to make the tracepoint footprint smaller:
      
         text	   data	    bss	    dec	    hex	filename
      4913961	1088356	 861512	6863829	 68bbd5	vmlinux.orig
      4914025	1088868	 861512	6864405	 68be15	vmlinux.class
      4918492	1084612	 861512	6864616	 68bee8	vmlinux.tracepoint
      
      Again, this patch also increases the size of the kernel, but
      lays the ground work for decreasing it.
      
       v5: Fixed net/core/drop_monitor.c to handle these updates.
      
       v4: Moved the DECLARE_TRACE() DECLARE_TRACE_NOARGS out of the
           #ifdef CONFIG_TRACE_POINTS, since the two are the same in both
           cases. The __DECLARE_TRACE() is what changes.
           Thanks to Frederic Weisbecker for pointing this out.
      
       v3: Made all register_* functions require data to be passed and
           all callbacks to take a void * parameter as its first argument.
           This makes the calling functions comply with C standards.
      
           Also added more comments to the modifications of DECLARE_TRACE().
      
       v2: Made the DECLARE_TRACE() have the ability to pass arguments
           and added a new DECLARE_TRACE_NOARGS() for tracepoints that
           do not need any arguments.
      Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      38516ab5
    • M
      tracepoints: Add check trace callback type · 53da59aa
      Mathieu Desnoyers 提交于
      This check is meant to be used by tracepoint users which do a direct cast of
      callbacks to (void *) for direct registration, thus bypassing the
      register_trace_##name and unregister_trace_##name checks.
      
      This permits to ensure that the callback type matches the function type at the
      call site, but without generating any code.
      Acked-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      LKML-Reference: <20100430165959.GA25605@Krystal>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Peter Zijlstra <peterz@infradead.org>
      CC: Arnaldo Carvalho de Melo <acme@redhat.com>
      CC: Lai Jiangshan <laijs@cn.fujitsu.com>
      CC: Li Zefan <lizf@cn.fujitsu.com>
      CC: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      53da59aa
  36. 05 5月, 2010 1 次提交
    • S
      tracing: Fix tracepoint.h DECLARE_TRACE() to allow more than one header · 2e26ca71
      Steven Rostedt 提交于
      When more than one header is included under CREATE_TRACE_POINTS
      the DECLARE_TRACE() macro is not defined back to its original meaning
      and the second include will fail to initialize the TRACE_EVENT()
      and DECLARE_TRACE() correctly.
      
      To fix this the tracepoint.h file moves the define of DECLARE_TRACE()
      out of the #ifdef _LINUX_TRACEPOINT_H protection (just like the
      define of the TRACE_EVENT()). This way the define_trace.h will undef
      the DECLARE_TRACE() at the end and allow new headers to start
      from scratch.
      
      This patch also requires fixing the include/events/napi.h
      
      It currently uses DECLARE_TRACE() and should be converted to a TRACE_EVENT()
      format. But I'll leave that change to the authors of that file.
      But since the napi.h file depends on using the CREATE_TRACE_POINTS
      and does not define its own DEFINE_TRACE() it must use the define_trace.h
      method instead.
      
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      2e26ca71