linux-kernel - RE: [PATCH] tracing: Add a debug_trace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e2f3ce97329d488d8ecd4fea5fbdb4f6@AcuMS.aculab.com>
Date:   Wed, 14 Jun 2023 09:57:33 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Steven Rostedt' <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>
CC:     Masami Hiramatsu <mhiramat@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Subject: RE: [PATCH] tracing: Add a debug_trace_printk() function

From: Steven Rostedt
> Sent: 13 June 2023 00:34
> 
> From: "Steven Rostedt (Google)" <rostedt@...dmis.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)