netdev - Re: netconsole: HARDIRQ-safe -> HARDIRQ-unsafe lock order warning

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] [day] [month] [year] [list]

Message-ID: <otlru5nr3g2npwplvwf4vcpozgx3kbpfstl7aav6rqz2zltvcf@famr4hqkwhuv>
Date: Wed, 20 Aug 2025 10:36:09 -0700
From: Breno Leitao <leitao@...ian.org>
To: Mike Galbraith <efault@....de>
Cc: Pavel Begunkov <asml.silence@...il.com>, 
	Jakub Kicinski <kuba@...nel.org>, Johannes Berg <johannes@...solutions.net>, paulmck@...nel.org, 
	LKML <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org, boqun.feng@...il.com
Subject: Re: netconsole: HARDIRQ-safe -> HARDIRQ-unsafe lock order warning

On Wed, Aug 20, 2025 at 02:31:02PM +0200, Mike Galbraith wrote:
> On Tue, 2025-08-19 at 10:27 -0700, Breno Leitao wrote:
> > 
> > I’ve continued investigating possible solutions, and it looks like
> > moving netconsole over to the non‑blocking console (nbcon) framework
> > might be the right approach. Unlike the classic console path, nbcon
> > doesn’t rely on the global console lock, which was one of the main
> > concerns regarding the possible deadlock.
> 
> ATM at least, classic can remotely log a crash whereas nbcon can't per
> test drive, so it would be nice for classic to stick around until nbcon
> learns some atomic packet blasting.

Oh, does it mean that during crash nbcon invokes `write_atomic` call
back, and because this patch doesn't implement it, it will not send
those pkts? Am I reading it correct?

> > The new path is protected by NETCONSOLE_NBCON, which is disabled by
> > default. This allows us to experiment and test both approaches.
> 
> As patch sits, interrupts being disabled is still a problem, gripes
> below.

You mean that the IRQs are disabled at the acquire of target_list_lock?
If so, an option is to turn that list an RCU list ?!

> Not disabling IRQs makes nbcon gripe free, but creates the
> issue of netpoll_tx_running() lying to the rest of NETPOLL consumers.
> 
> RT and the wireless stack have in common that IRQs being disabled in
> netpoll.c sucks rocks for them.  I've been carrying a hack to allow RT
> to use netconsole since 5.15, and adapted it to squelch nbcons inspired
> gripes as well (had to whack irqsave/restore in your patch as well). 
> Once the dust settles, perhaps RT can simply select NETCONSOLE_NBCON to
> solve its netconsole woes for free.

What is this patch you have?

Thanks
--breno