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

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Jun 11, 2026 at 09:53:45PM -0400, Rik van Riel wrote:
> 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.

I've not hit OOM in a decade or so; I've no idea how much silly nonsense
it spouts. The example the printk people have used for a long while is
booting with a million block devices, apparently that generates insane
amount of boot noise -- another problem I don't have :-)

Anyway, one solution there is to create a threshold and say ERR and
above go directly to atomic console while everything below goes into the
buffer and gets spooled out later on the non-atomic variant.

This way all your WARN/BUG and other useful bits actually hit the wire
when you need them, and the useless verbiage goes into the bin for
later.

Anyway, all this is stuff that seems trivially solvable.