Skip to content

tracing: Enable tracepoints early and allow printk to use them

Steven Rostedt lkml 2 versions In review

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v2 Latest2 patches 3 repliesIn review
  2. v13 patches 16 repliesSuperseded

Patches in v2 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2tracing: Move enabling tracepoints to just after rcu_init()include/linux/ftrace.h init/main.c kernel/trace/trace.c +3 more+40 -81 reply
2/2tracing: Add tp_printk cmdline to have tracepoints go to printk()Documentation/kernel-parameters.txt include/linux/ftrace.h kernel/sysctl.c +3 more+76 -00 replies

Reviews trailers per patch

1 of 2 patches has a Reviewed-by or Acked-by.

PatchPaul E. McKenneyThomas Gleixner
SeriesTested-and-acked-by
1/2R-b
2/2

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v2 thread

Cover letter [PATCH 0/2 v2] tracing: Enable tracepoints early and allow printk to use them

Version 2:

Removed the update to tracepoint.c code and just call trace_init() after rcu_init() where call_rcu_sched() can be used.

Version 1 at: http://lkml.kernel.org/r/[email protected]

This adds two new features:

1) Allow traceopoints to be enabled right after mm_init(). By passing in the trace_event= kernel command line parameter, tracepoints can be enabled at boot up. For debugging things like the initialization of interrupts, it is needed to have tracepoints enabled very early. People have asked about this before and this has been on my todo list. As it can be helpful for Thomas to debug his upcoming 3.20 IRQ work, I'm pushing this now. This way he can add tracepoints into the IRQ set up and have have users enable them when things go wrong.

2) Have the tracepoints printed via printk() (the console) when they are triggered. If the irq code locks up or reboots the box, having the tracepoint output go into the kernel ring buffer is useless for debugging. But being able to add the tp_printk kernel command line option along with the trace_event= option will have these tracepoints printed as they occur, and that can be really useful for debugging early lock up or reboot problems.

As the merge window is still open, and this code was not as complex as I thought it might be. I'm thinking of pushing this in now.

This will allow Thomas to debug his irq work for 3.20.

This code is not that intrusive and I'm currently running it through all my tests. But I like to have some more eyes on this, as I don't like to push something into mainline this quickly. I'm doing this only because the code is simple enough and is useful for work coming in 3.20.

I also feel that I could handle the fall out of this work over the holidays if need be.

Steven Rostedt (Red Hat) (2):
tracing: Move enabling tracepoints to just after rcu_init()
tracing: Add tp_printk cmdline to have tracepoints go to printk()

----

 Documentation/kernel-parameters.txt | 18 ++++++++++++++++
 include/linux/ftrace.h              |  7 +++++++
 init/main.c                         |  4 ++++
 kernel/sysctl.c                     |  7 +++++++
 kernel/trace/trace.c                | 25 +++++++++++++++++++++-
 kernel/trace/trace.h                | 14 +++++++++++++
 kernel/trace/trace_events.c         | 42 +++++++++++++++++++++++++++++++++++--
 kernel/trace/trace_syscalls.c       |  7 ++-----
 8 files changed, 116 insertions(+), 8 deletions(-)