Re: [PATCH net-next 0/2] net: netconsole: convert to NBCON console infrastructure

[John Ogness]

Hi Breno,

On 2026-01-07, Breno Leitao <leitao@xxxxxxxxxx> wrote:
> 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())

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@xxxxxxxxxxx