linux-kernel - Re: [PATCH v2 08/12] nova-core: sequencer: Add register opcodes

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: <974877EE-0B3D-4723-B3F1-0BFCFCC9D2E6@nvidia.com>
Date: Mon, 10 Nov 2025 17:09:00 +0000
From: Joel Fernandes <joelagnelf@...dia.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: Timur Tabi <ttabi@...dia.com>, John Hubbard <jhubbard@...dia.com>,
	"dakr@...nel.org" <dakr@...nel.org>, "lossin@...nel.org" <lossin@...nel.org>,
	"ojeda@...nel.org" <ojeda@...nel.org>, "boqun.feng@...il.com"
	<boqun.feng@...il.com>, "a.hindborg@...nel.org" <a.hindborg@...nel.org>,
	"simona@...ll.ch" <simona@...ll.ch>, "tmgross@...ch.edu" <tmgross@...ch.edu>,
	"alex.gaynor@...il.com" <alex.gaynor@...il.com>, "mripard@...nel.org"
	<mripard@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "maarten.lankhorst@...ux.intel.com"
	<maarten.lankhorst@...ux.intel.com>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "nouveau@...ts.freedesktop.org"
	<nouveau@...ts.freedesktop.org>, "rust-for-linux@...r.kernel.org"
	<rust-for-linux@...r.kernel.org>, "gary@...yguo.net" <gary@...yguo.net>,
	"bjorn3_gh@...tonmail.com" <bjorn3_gh@...tonmail.com>, "tzimmermann@...e.de"
	<tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>,
	"aliceryhl@...gle.com" <aliceryhl@...gle.com>, Alexandre Courbot
	<acourbot@...dia.com>, "joel@...lfernandes.org" <joel@...lfernandes.org>,
	Alistair Popple <apopple@...dia.com>
Subject: Re: [PATCH v2 08/12] nova-core: sequencer: Add register opcodes



> On Nov 10, 2025, at 11:59 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> On Mon, 10 Nov 2025 10:16:45 -0500
> Joel Fernandes <joelagnelf@...dia.com> wrote:
> 
>>> IMO, the best way to do this is the tracing subsystem. It is the lowest overhead
>>> runtime kernel logging system that I know off, lockless, independent of the
>>> serial console etc, next to no runtime overhead when off, etc.
>>> 
>>> I recommend we use the tracing subsystem for "trace" and even "spam" level
>>> logging levels for Nova. The brave souls can always ask the tracing subsystem to
>>> also spam to kernel logs if they so wish.
>>> 
>>> ++ Tracing Czar Steven Rostedt as well. Steve, Nova is a new modern Nvidia GPU
>>> driver.
> 
> Not sure if there was a question here, but you can enable tracing via the
> kernel command line and it will record into the ring buffer, and read it
> out via /sys/kernel/tracing/trace. You could also create instances by the
> kernel command line that will place events in different ring buffer
> instances (/sys/kernel/tracing/instances/<instance>/trace). You could even
> filter the events based on the trace event fields, process ID, CPU, etc.
> 
> There's also a tp_printk kernel command line option that will turn every
> trace event into a printk() statement. You need to be careful of what
> events you enable when doing this, as some events (like locking events) can
> live lock the system if they are piped to printk().
> 
> After boot up, you can turn off the tp_printk with:
> 
>  echo 0 > /proc/sys/kernel/tracepoint_printk

Thanks Steve. The reason I also added you was also to keep me honest about tracing performance for logging that is noisy. 

The context is dev_dbg noise can have strong side effects that tracing will for sure circumvent.

I would keep dmesg printing only for info/error/warning with tracing for the noisy ones.

Maybe we should add a facility to dynamically turn all dev_dbg into tracing…

Thanks,

- Joel


> 
> -- Steve
> 
>>> 
>>> I guess we have to decide how to do this - what kind of tracepoints do we need
>>> for Nova. One use case that just came up is RPC message buffer dumps for
>>> debugging communication with the firmware.