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

[John Ogness <john.ogness@linutronix.de>]

On 2025-09-10, Breno Leitao <leitao@debian.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