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: <20251229111748.3ba66311@gandalf.local.home>
Date: Mon, 29 Dec 2025 11:17:48 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Yury Norov (NVIDIA)" <yury.norov@...il.com>, Masami Hiramatsu
 <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Christophe Leroy
 <chleroy@...nel.org>, Randy Dunlap <rdunlap@...radead.org>, Ingo Molnar
 <mingo@...nel.org>, Jani Nikula <jani.nikula@...ux.intel.com>, Joonas
 Lahtinen <joonas.lahtinen@...ux.intel.com>, David Laight
 <david.laight@...box.com>, Petr Pavlu <petr.pavlu@...e.com>, Andi Shyti
 <andi.shyti@...nel.org>, Rodrigo Vivi <rodrigo.vivi@...el.com>, Tvrtko
 Ursulin <tursulin@...ulin.net>, Daniel Gomez <da.gomez@...nel.org>, Greg
 Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki"
 <rafael@...nel.org>, Danilo Krummrich <dakr@...nel.org>,
 linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
 dri-devel@...ts.freedesktop.org, linux-modules@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h

On Sun, 28 Dec 2025 13:31:50 -0800
Andrew Morton <akpm@...ux-foundation.org> wrote:

> > trace_printk() should be as available to the kernel as printk() is.  
> 
> um, why?  trace_printk is used 1% as often as is printk.  Seems
> reasonable to include a header file to access such a rarely-used(!) and
> specialized thing?

It will waste a lot of kernel developers time. Go to conferences and talk
with developers. trace_printk() is now one of the most common ways to debug
your code. Having to add "#include <linux/trace_printk.h>" in every file
that you use trace_printk() (and after your build fails because you forgot
to include that file **WILL** slow down kernel debugging for hundreds of
developers! It *is* used more than printk() for debugging today. Because
it's fast and can be used in any context (NMI, interrupt handlers, etc).

But sure, if you want to save the few minutes that is added to "make
allyesconfig" by sacrificing minutes of kernel developer's time. Go ahead
and make this change.

I don't know how much you debug and develop today, but lots of people I
talk to at conferences thank me for trace_printk() because it makes
debugging their code so much easier.

The "shotgun" approach is very common. That is, you add:

	trace_printk("%s:%d\n", __func__, __LINE__);

all over your code to find out where things are going wrong. With the
persistent ring buffer, you can even extract that information after a
crash and reboot.

There's very few instances of it in the kernel because I made it that way.
If you add a trace_printk() in the kernel, you get the banner:

 **********************************************************
 **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
 **                                                      **
 ** trace_printk() being used. Allocating extra memory.  **
 **                                                      **
 ** This means that this is a DEBUG kernel and it is     **
 ** unsafe for production use.                           **
 **                                                      **
 ** If you see this message and you are not debugging    **
 ** the kernel, report this immediately to your vendor!  **
 **                                                      **
 **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
 **********************************************************

in your dmesg.

I've been recommending people that if you find a "trace_printk()" useful,
you should convert it into a normal TRACE_EVENT() for submission. Which
many developers have done.

Yes, it's not in your kernel, but it is in several other people's kernels
as they develop it. And adding a requirement that they need to include a
header file for every place they add it (and then have to remember to
remove that header file when they are done debugging) is going to waste
more precious time that kernel developers don't have much of.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ