Hi Breno,

On 2026-01-07, Breno Leitao [off-list ref] wrote:

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

quoted

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())

I was not aware of this netconsole feature until now.

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).

Note that even with legacy consoles there was never a guarantee that the
printing context is the same CPU/task as the printk() caller. It was
just much more likely.

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.

But by the time the printer is active, that task may no longer exist,
may have migrated to a different CPU and/or may be sleeping.

IIUC, basically you want to attach console-specific additional
information to ringbuffer records, but only that specific console should
see/use the additional information. In this case it could be up to 4+16
additional bytes (depending on @sysdata_fields).

A while ago we had a discussion[0] about adding custom
information. There I even went so far as to suggest supporting things
like a new boot argument:

    printk.format=ts,cpu,comm,pid,in_atomic

(which could also be console-specific)

The result of the discussion was killing off dictionaries (that allowed
variable length custom data) and replacing them with the dev_printk_info
struct.

I am just pointing out that this kind of discussion has existed in the
past and not suggesting that we should reintroduce dictionaries.


A simple fix could be to add an extra 36-byte struct to both
dev_printk_info and nbcon_write_context that exists conditionally on
CONFIG_NETCONSOLE_DYNAMIC.

vprintk_store() would set the extra data to dev_printk_info.

nbcon_emit_next_record() would copy the data to nbcon_write_context.

John Ogness

[0] https://lore.kernel.org/lkml/20200904082438.20707-1-changki.kim@samsung.com (local)