Messages in this thread | | | Date | Fri, 6 Oct 2023 14:53:36 +0200 | From | Petr Mladek <> | Subject | panic context: was: Re: [PATCH printk v2 04/11] printk: nbcon: Provide functions to mark atomic write sections |
| |
(2nd attempt with with Linus really in Cc).
Adding Linus into Cc. I would like to be sure about the flushing of atomic consoles in panic context.
> During the demo at LPC2022 we had the situation that there was a large > backlog when a WARN was hit. With current mainline the first line of the > WARN is put into the ringbuffer and then the entire backlog is flushed > before storing the rest of the WARN into the ringbuffer. At the time it > was obvious that we should finish storing the WARN message and then > start flushing the backlog.
This talks about the "emergency" context (WARN/OOPS/watchdog). The system might be in big troubles but it would still try to continue.
Do we really want to defer the flush also for panic() context?
I ask because I was not on LPC 2022 in person and I do not remember all details.
Anyway, the deferred flush works relatively well for the "emergency" context:
+ flushed from nbcon_atomic_exit() + printk kthread might emit the messages while they are being added
But it is tricky in panic(), see 8th patch at https://lore.kernel.org/r/20230919230856.661435-9-john.ogness@linutronix.de
+ nbcon_atomic_exit() is called only in one code path.
+ nbcon_atomic_flush_all() is used in other paths. It looks like a "Whack a mole" game to me.
+ messages are never emitted by printk kthread either because CPUs are stopped or the kthread is not allowed to get the lock[*]
I see only one positive of the explicit flush. The consoles would not delay crash_exec() and the crash dump might be closer to the point where panic() was called.
Otherwise I see only negatives => IMHO, we want to flush atomic consoles synchronously from printk() in panic().
Does anyone really want explicit flushes in panic()?
[*] Emitting messages is explicitly blocked on non-panic CPUs. It increases the change that panic-CPU would be able to take the console lock the safe way.
Best Regards, Petr
| |