Hello Petr, John and Marcos,

On Mon, Dec 22, 2025 at 06:52:09AM -0800, Breno Leitao wrote:

This series adds support for the nbcon (new buffer console) infrastructure
to netconsole, enabling lock-free, priority-based console operations that
are safer in crash scenarios.

I've been reflecting further on this port and encountered a potential
roadblock that I'd like to discuss to ensure I'm heading in the right
direction.

Netconsole appends additional data (sysdata) to messages, specifically
the CPU and task_struct->comm fields.

Basically, it appends current->comm and raw_smp_processor_id()
when sending a message.
(For more details, see sysdata_append_cpu_nr() and
sysdata_append_taskname())

With nbcon, since netconsole will operate on a separate thread, this
sysdata may become inaccurate (the data would reflect the printk thread
rather than the original task or CPU that generated the message).

Upon reviewing the printk subsystem, I noticed that struct
printk_info->caller_id stores similar information, but not exactly the
same. It contains either the CPU *or* the task, not both, and this data
isn't easily accessible from within the ->write_thread() context. 

One possible solution that comes to my mind is to pass both the CPU ID
and the task_struct/vpid to struct printk_info, and then integrate this
into struct nbcon_write_context *wctxt somehow.

This way, netconsole could reliably query the original CPU and task that
generated the message, regardless of where the netconsole code is
executed.

How crazy is this approach?