Message-ID: <87zf6pfmlq.fsf@jogness.linutronix.de>
Date: Wed, 07 Jan 2026 16:56:41 +0106
From: John Ogness <john.ogness@...utronix.de>
To: Breno Leitao <leitao@...ian.org>, pmladek@...e.com, mpdesouza@...e.com
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 asantostc@...il.com, efault@....de, gustavold@...il.com,
 calvin@...nvd.org, jv@...sburgh.net, kernel-team@...a.com, Petr Mladek
 <pmladek@...e.com>, Simon Horman <horms@...nel.org>, Andrew Lunn
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, rostedt@...dmis.org
Subject: Re: [PATCH net-next 0/2] net: netconsole: convert to NBCON console
 infrastructure

Hi Breno,

On 2026-01-07, Breno Leitao <leitao@...ian.org> 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@samsung.com

Powered by blists - more mailing lists