Re: [PATCH 0/9] sched: make WARN_ON under rq->lock deadlock-safe (SCHED_WARN_ON)

[Rik van Riel]

On Thu, 2026-06-11 at 21:19 +0200, Peter Zijlstra wrote:
> 
> Myself, I almost exclusively run with earlycon serial and force
> printk
> to be early_printk() (effectively not using printk at all). This
> works
> perfectly fine and is the most reliable thing ever. I can push out
> characters to the UART from any context.
> 
Great for development, not so good for production.

When something like an OOM kill happens, the amount
of data printed by the kernel can take a long time
to get flushed out a serial port.

In fact, it can take long enough to cause things
like RCU stalls and soft lockups, and break
workloads that way.

Having the serial console deferred allows those
systems to survive.

If the system crashes before the messages were sent
out the serial port, the dmesg buffer will be in
the vmcore, and get extracted by the crash analysis
tooling.

It sounds like the printk people may be right with
making that behavior an option, since different
scenarios require different behavior.

-- 
All Rights Reversed.