aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/ftrace_event.h
diff options
context:
space:
mode:
authorSteven Rostedt (Red Hat) <rostedt@goodmis.org>2013-07-12 17:07:27 -0400
committerSteven Rostedt <rostedt@goodmis.org>2013-07-26 13:39:44 -0400
commit102c9323c35a83789ad5ebd3c45fa8fb389add88 (patch)
tree1774b9144e5a00a49358475c1aca9ad33713e417 /include/linux/ftrace_event.h
parent3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b (diff)
tracing: Add __tracepoint_string() to export string pointers
There are several tracepoints (mostly in RCU), that reference a string pointer and uses the print format of "%s" to display the string that exists in the kernel, instead of copying the actual string to the ring buffer (saves time and ring buffer space). But this has an issue with userspace tools that read the binary buffers that has the address of the string but has no access to what the string itself is. The end result is just output that looks like: rcu_dyntick: ffffffff818adeaa 1 0 rcu_dyntick: ffffffff818adeb5 0 140000000000000 rcu_dyntick: ffffffff818adeb5 0 140000000000000 rcu_utilization: ffffffff8184333b rcu_utilization: ffffffff8184333b The above is pretty useless when read by the userspace tools. Ideally we would want something that looks like this: rcu_dyntick: Start 1 0 rcu_dyntick: End 0 140000000000000 rcu_dyntick: Start 140000000000000 0 rcu_callback: rcu_preempt rhp=0xffff880037aff710 func=put_cred_rcu 0/4 rcu_callback: rcu_preempt rhp=0xffff880078961980 func=file_free_rcu 0/5 rcu_dyntick: End 0 1 The trace_printk() which also only stores the address of the string format instead of recording the string into the buffer itself, exports the mapping of kernel addresses to format strings via the printk_format file in the debugfs tracing directory. The tracepoint strings can use this same method and output the format to the same file and the userspace tools will be able to decipher the address without any modification. The tracepoint strings need its own section to save the strings because the trace_printk section will cause the trace_printk() buffers to be allocated if anything exists within the section. trace_printk() is only used for debugging and should never exist in the kernel, we can not use the trace_printk sections. Add a new tracepoint_str section that will also be examined by the output of the printk_format file. Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Diffstat (limited to 'include/linux/ftrace_event.h')
-rw-r--r--include/linux/ftrace_event.h34
1 files changed, 34 insertions, 0 deletions
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 4372658c73ae..81af18a75f4d 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -357,6 +357,40 @@ do { \
357 __trace_printk(ip, fmt, ##args); \ 357 __trace_printk(ip, fmt, ##args); \
358} while (0) 358} while (0)
359 359
360/**
361 * tracepoint_string - register constant persistent string to trace system
362 * @str - a constant persistent string that will be referenced in tracepoints
363 *
364 * If constant strings are being used in tracepoints, it is faster and
365 * more efficient to just save the pointer to the string and reference
366 * that with a printf "%s" instead of saving the string in the ring buffer
367 * and wasting space and time.
368 *
369 * The problem with the above approach is that userspace tools that read
370 * the binary output of the trace buffers do not have access to the string.
371 * Instead they just show the address of the string which is not very
372 * useful to users.
373 *
374 * With tracepoint_string(), the string will be registered to the tracing
375 * system and exported to userspace via the debugfs/tracing/printk_formats
376 * file that maps the string address to the string text. This way userspace
377 * tools that read the binary buffers have a way to map the pointers to
378 * the ASCII strings they represent.
379 *
380 * The @str used must be a constant string and persistent as it would not
381 * make sense to show a string that no longer exists. But it is still fine
382 * to be used with modules, because when modules are unloaded, if they
383 * had tracepoints, the ring buffers are cleared too. As long as the string
384 * does not change during the life of the module, it is fine to use
385 * tracepoint_string() within a module.
386 */
387#define tracepoint_string(str) \
388 ({ \
389 static const char *___tp_str __tracepoint_string = str; \
390 ___tp_str; \
391 })
392#define __tracepoint_string __attribute__((section("__tracepoint_str")))
393
360#ifdef CONFIG_PERF_EVENTS 394#ifdef CONFIG_PERF_EVENTS
361struct perf_event; 395struct perf_event;
362 396