linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] tracing: Add a debug_trace_printk() function
@ 2023-06-12 23:33 Steven Rostedt
  2023-06-14  9:57 ` David Laight
  0 siblings, 1 reply; 3+ messages in thread
From: Steven Rostedt @ 2023-06-12 23:33 UTC (permalink / raw)
  To: LKML, Linux Trace Kernel; +Cc: Masami Hiramatsu, Mark Rutland

From: "Steven Rostedt (Google)" <rostedt@goodmis.org>

While doing some tracing and kernel debugging, I found that some of my
trace_printk()s were being lost in the noise of the other code that was
being traced. Having a way to write trace_printk() not in the top level
trace buffer would have been useful.

There was also a time I needed to debug ftrace itself, where
trace_printk() did not hit the paths that were being debugged. But because
the trace that was being debugged, was going into the top level ring
buffer, it was causing issues for seeing what is to be traced.

To solve both of the above, add a debug_trace_printk() that can be used
just like trace_printk() except that it goes into a "debug" instance
buffer instead. This can be used at boot up as well.

Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
 include/linux/kernel.h | 14 ++++++++++++++
 kernel/trace/Kconfig   | 20 ++++++++++++++++++++
 kernel/trace/trace.c   | 29 +++++++++++++++++++++++++++++
 3 files changed, 63 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 0d91e0af0125..594c9ba17fd4 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -432,6 +432,20 @@ __ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap);
 extern __printf(2, 0) int
 __ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
 
+#ifdef CONFIG_FTRACE_DEBUG_PRINT
+extern __printf(2,0) void do_debug_trace_printk(unsigned long ip, const char *fmt, ...);
+#define debug_trace_printk(fmt, ...) \
+do {							\
+	do_debug_trace_printk(_THIS_IP_, fmt, ##__VA_ARGS__);	\
+} while (0)
+
+extern void debug_tracing_stop(void);
+#else
+#define debug_trace_printk(fmt, ...) do { } while (0)
+static inline void debug_tracing_stop(void) { }
+#endif
+
+
 extern void ftrace_dump(enum ftrace_dump_mode oops_dump_mode);
 #else
 static inline void tracing_start(void) { }
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index abe5c583bd59..eb102070e9e6 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -974,6 +974,26 @@ config GCOV_PROFILE_FTRACE
 	  Note that on a kernel compiled with this config, ftrace will
 	  run significantly slower.
 
+config FTRACE_DEBUG_PRINT
+	bool
+	depends on TRACING
+	help
+	  This option enables the use of debug_trace_printk() instead of
+	  using trace_printk(). The difference between the two is that
+	  debug_trace_printk() traces are visible in the "debug" instance
+	  found in:
+
+	  /sys/kernel/tracing/instances/debug
+
+	  This is useful when the trace printks should not interfere with
+	  the normal top level tracing. It is also useful if the top level
+	  tracing is very noisy and critical trace printks are dropped.
+	  By using debug_trace_printk() the traces goes into as separate
+	  ring buffer that will not be overridden by other trace events.
+
+	  If unsure say N (In fact, only say Y if you are debugging a
+	                   kernel and require this)
+
 config FTRACE_SELFTEST
 	bool
 
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 64a4dde073ef..c21a93cf5fd8 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -490,6 +490,10 @@ static struct trace_array global_trace = {
 	.trace_flags = TRACE_DEFAULT_FLAGS,
 };
 
+#ifdef CONFIG_FTRACE_DEBUG_PRINT
+static struct trace_array *debug_trace;
+#endif
+
 LIST_HEAD(ftrace_trace_arrays);
 
 int trace_array_get(struct trace_array *this_tr)
@@ -10455,8 +10459,33 @@ void __init early_trace_init(void)
 	tracer_alloc_buffers();
 
 	init_events();
+
+#ifdef CONFIG_FTRACE_DEBUG_PRINT
+	debug_trace = trace_array_get_by_name("debug");
+	if (WARN_ON(!debug_trace))
+		return;
+	trace_array_init_printk(debug_trace);
+#endif
 }
 
+#ifdef CONFIG_FTRACE_DEBUG_PRINT
+__printf(2, 0)
+void do_debug_trace_printk(unsigned long ip, const char *fmt, ...)
+{
+	va_list ap;
+
+	va_start(ap, fmt);
+	trace_array_vprintk(debug_trace, ip, fmt, ap);
+	va_end(ap);
+}
+
+void debug_tracing_stop(void)
+{
+	debug_trace_printk("Stopping debug tracing\n");
+	tracing_stop_tr(debug_trace);
+}
+#endif
+
 void __init trace_init(void)
 {
 	trace_event_init();
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* RE: [PATCH] tracing: Add a debug_trace_printk() function
  2023-06-12 23:33 [PATCH] tracing: Add a debug_trace_printk() function Steven Rostedt
@ 2023-06-14  9:57 ` David Laight
  2023-06-14 13:43   ` Steven Rostedt
  0 siblings, 1 reply; 3+ messages in thread
From: David Laight @ 2023-06-14  9:57 UTC (permalink / raw)
  To: 'Steven Rostedt', LKML, Linux Trace Kernel
  Cc: Masami Hiramatsu, Mark Rutland

From: Steven Rostedt
> Sent: 13 June 2023 00:34
> 
> From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
> 
> While doing some tracing and kernel debugging, I found that some of my
> trace_printk()s were being lost in the noise of the other code that was
> being traced. Having a way to write trace_printk() not in the top level
> trace buffer would have been useful.
> 
> There was also a time I needed to debug ftrace itself, where
> trace_printk() did not hit the paths that were being debugged. But because
> the trace that was being debugged, was going into the top level ring
> buffer, it was causing issues for seeing what is to be traced.
> 
> To solve both of the above, add a debug_trace_printk() that can be used
> just like trace_printk() except that it goes into a "debug" instance
> buffer instead. This can be used at boot up as well.
...
> +#ifdef CONFIG_FTRACE_DEBUG_PRINT
> +	debug_trace = trace_array_get_by_name("debug");
> +	if (WARN_ON(!debug_trace))
> +		return;
> +	trace_array_init_printk(debug_trace);
> +#endif

I was wondering if that could be done whenever the "debug"
trace_array is created?
(perhaps only if trace_prink() has been used?)
Since (AFAICT) it could be created at any time??

So you wouldn't really need an extra kernel knob?
(Except to get the boot time trace diverted.)
The trace could go to the global buffer if the debug one
isn't created.

OTOH I'm missing what trace_array_init_prink() does?
It seems to just call alloc_percpu_trace_buffer() with
no arguments.

It looks like alloc_percpu_trace_buffer() is called if there
are any trace_printk() formats in the main kernel.
Hopefully they aren't just in modules??

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] tracing: Add a debug_trace_printk() function
  2023-06-14  9:57 ` David Laight
@ 2023-06-14 13:43   ` Steven Rostedt
  0 siblings, 0 replies; 3+ messages in thread
From: Steven Rostedt @ 2023-06-14 13:43 UTC (permalink / raw)
  To: David Laight; +Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mark Rutland

On Wed, 14 Jun 2023 09:57:33 +0000
David Laight <David.Laight@ACULAB.COM> wrote:

> From: Steven Rostedt
> > Sent: 13 June 2023 00:34
> > 
> > From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
> > 
> > While doing some tracing and kernel debugging, I found that some of my
> > trace_printk()s were being lost in the noise of the other code that was
> > being traced. Having a way to write trace_printk() not in the top level
> > trace buffer would have been useful.
> > 
> > There was also a time I needed to debug ftrace itself, where
> > trace_printk() did not hit the paths that were being debugged. But because
> > the trace that was being debugged, was going into the top level ring
> > buffer, it was causing issues for seeing what is to be traced.
> > 
> > To solve both of the above, add a debug_trace_printk() that can be used
> > just like trace_printk() except that it goes into a "debug" instance
> > buffer instead. This can be used at boot up as well.  
> ...
> > +#ifdef CONFIG_FTRACE_DEBUG_PRINT
> > +	debug_trace = trace_array_get_by_name("debug");
> > +	if (WARN_ON(!debug_trace))
> > +		return;
> > +	trace_array_init_printk(debug_trace);
> > +#endif  
> 
> I was wondering if that could be done whenever the "debug"
> trace_array is created?
> (perhaps only if trace_prink() has been used?)
> Since (AFAICT) it could be created at any time??
> 
> So you wouldn't really need an extra kernel knob?
> (Except to get the boot time trace diverted.)
> The trace could go to the global buffer if the debug one
> isn't created.

I'd rather not touch trace_printk(), that would just confuse people more.

Anyway, I'm not going to apply this. I have other ideas on how to
accomplish this. But for now, I wanted it in my patchwork to remind me to
do those other methods. In the mean time, I can just apply this patch
when I need to.

> 
> OTOH I'm missing what trace_array_init_prink() does?
> It seems to just call alloc_percpu_trace_buffer() with
> no arguments.
> 
> It looks like alloc_percpu_trace_buffer() is called if there
> are any trace_printk() formats in the main kernel.
> Hopefully they aren't just in modules??

No, they are allocated if a module uses them too. Try it out. Load a module
with trace_printk() and you'll see that banner print out.

-- Steve

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-06-14 13:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-12 23:33 [PATCH] tracing: Add a debug_trace_printk() function Steven Rostedt
2023-06-14  9:57 ` David Laight
2023-06-14 13:43   ` Steven Rostedt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).