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: <84ecsdxhbi.fsf@jogness.linutronix.de>
Date: Thu, 11 Sep 2025 15:19:53 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Breno Leitao <leitao@...ian.org>
Cc: Mike Galbraith <efault@....de>, Simon Horman <horms@...nel.org>,
 kuba@...nel.org, calvin@...nvd.org, Pavel Begunkov
 <asml.silence@...il.com>, Johannes Berg <johannes@...solutions.net>,
 paulmck@...nel.org, LKML <linux-kernel@...r.kernel.org>,
 netdev@...r.kernel.org, boqun.feng@...il.com, Petr Mladek
 <pmladek@...e.com>, Sergey Senozhatsky <senozhatsky@...omium.org>, Steven
 Rostedt <rostedt@...dmis.org>
Subject: Re: netconsole: HARDIRQ-safe -> HARDIRQ-unsafe lock order warning

On 2025-09-10, Breno Leitao <leitao@...ian.org> wrote:
>> d) Not implementing ->write_atomic() and instead implement a kmsg_dumper
>>    for netconsole. This registers a callback that is called during
>>    panic.
>> 
>>    Con: The kmsg_dumper interface has nothing to do with consoles, so it
>>         would require some effort coordinating with the console drivers.
>
> I am looking at kmsg_dumper interface, and it doesn't have the buffers
> that need to be dumper.
>
> So, if I understand corect, my kmsg_dumper callback needs to handle loop
> into the messages buffer and print the remaining messages, right?

Correct.

> In other words, do I need to track what messages were sent in
> netconsole, and then iterate in the kmsgs buffer 
> to find messages that hasn't been sent, and send from there?

Yes, right now it would not even be possible to do the proper tracking
since the sequence numbers are not exposed to the console printers and
they are not part of kmsg_dump interface.

As it is right now, the kmsg_dumper would just print what is available
in the ringbuffer, even if most of the messages have already been
printed during runtime. Certainly not optimal.

>>    Pro: There is absolute freedom for the dumper to implement its own
>>         panic-only solution to get messages out.
>
> What about calls to .write_atomic() calls that are not called during
> panic? Will those be lost in this approach?

In this approach you would not implement ->write_atomic(), so there
would be no such calls. All printing would be deferred to the dedicated
printing kthread.

Anyway, it looks like we have agreed to allow unsafe ->write_atomic()
callbacks.

John