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 09:43 +0200, Peter Zijlstra wrote:
> 
> Sorry, no. I've said it before and I'll stick with it. Just no.
> 
> printk_deferred() is an abomination, it means that if you mess up the
> machine properly you'll *NEVER* see the output.
> 
> As per always, printk() is the one that needs fixing, and IIRC they
> were
> very close to getting there.

Printk to certain console types is always deferred,
by default, because trying to synchronously print
everything to a slow serial console can lead to a
system softlockup panic.

In fact, this particular lockup is due to the
printk being passed off to a worker thread, and
the kernel deadlocking when the wakeup code
tries to grab the runqueue lock its CPU already
holds.

You are right that this could be fixed in the
printk code, but the solution there will by
necessity continue to contain some deferring.


I suppose the printk code could use something
like an irq work to wake up the printk worker,
and avoid the scheduler deadlock that way?

I'm not sure that would make things more
reliable, though...

-- 
All Rights Reversed.