linux-kernel - Re: [PATCH net-next v5 3/4] netconsole: convert to NBCON console infrastructure

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: <aXt6bD4KNb-5aY6c@pathway.suse.cz>
Date: Thu, 29 Jan 2026 16:19:08 +0100
From: Petr Mladek <pmladek@...e.com>
To: Breno Leitao <leitao@...ian.org>
Cc: 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>,
	john.ogness@...utronix.de,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Sergey Senozhatsky <senozhatsky@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, asantostc@...il.com, efault@....de,
	gustavold@...il.com, calvin@...nvd.org, jv@...sburgh.net,
	mpdesouza@...e.com, kernel-team@...a.com
Subject: Re: [PATCH net-next v5 3/4] netconsole: convert to NBCON console
 infrastructure

On Wed 2026-01-28 06:17:39, Breno Leitao wrote:
> Convert netconsole from the legacy console API to the NBCON framework.
> NBCON provides threaded printing which unblocks printk()s and flushes in
> a thread, decoupling network TX from printk() when netconsole is
> in use.
> 
> Since netconsole relies on the network stack which cannot safely operate
> from all atomic contexts, mark both consoles with
> CON_NBCON_ATOMIC_UNSAFE. (See discussion in [1])
> 
> CON_NBCON_ATOMIC_UNSAFE restricts write_atomic() usage to emergency
> scenarios (panic) where regular messages are sent in threaded mode.
> 
> Implementation changes:
> - Unify write_ext_msg() and write_msg() into netconsole_write()
> - Add device_lock/device_unlock callbacks to manage target_list_lock
> - Use nbcon_enter_unsafe()/nbcon_exit_unsafe() around network
>   operations.
>   - If nbcon_enter_unsafe() fails, just return given netconsole lost
>     the ownership of the console.

I was just curious and scratched my head around this a bit.
If I get it correctly then it might fail only in a single situation.
It actually should never happen on systems which stop CPUs by NMI.

My thiking is:

  1. nbcon->write_thread() is called only from the dedicated kthread
     so that there is always only one instance.

     It might actually be called also by the legacy loop when a boot
     console is registed. But the kthread is blocked in this case.

     Anyway, the callback is serialized also using netcon->device_lock().


  2. nbcon->write_atomic() is called only by the final
     nbcon_atomic_flush_unsafe() because of CON_NBCON_ATOMIC_UNSAFE.

     nbcon_enter_unsafe() always succeeds here because the _usafe_
     takeover is allowed.


  3. No other lock is synchronized with nbcon context.

     It is acceptable because nbcon->write_atomic() is called
     only by nbcon_atomic_flush_unsafe() where the nbcon context
     synchronization is ignored anyway.

So, nbcon_enter_unsafe() might fail only in netcon->write_thread()
when the kthread is still running on another CPU while
nbcon_atomic_flush_unsafe() is called on the panic CPU.

And it should never happen when the non-panic CPUs are stopped
by NMI.

By other words, the nbcon context synchronization does not have
much value when CON_NBCON_ATOMIC_UNSAFE is used.

It is acceptable from my POV. I write this just to make
the expectations clear. I wish, I had time to write a more
comprehensible documentation about the printk design...

> - Set write_thread and write_atomic callbacks (both use same function)
> 
> Link: https://lore.kernel.org/all/b2qps3uywhmjaym4mht2wpxul4yqtuuayeoq4iv4k3zf5wdgh3@tocu6c7mj4lt/ [1]
> Signed-off-by: Breno Leitao <leitao@...ian.org>

Feel free to use:

Reviewed-by: Petr Mladek <pmladek@...e.com>

Best Regards,
Petr