From: Rik van Riel <riel@surriel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
vschneid@redhat.com
Subject: Re: [PATCH 0/9] sched: make WARN_ON under rq->lock deadlock-safe (SCHED_WARN_ON)
Date: Thu, 11 Jun 2026 12:20:27 -0400 [thread overview]
Message-ID: <bc61cec71c284361882b5cc19f8520e2e85ec133.camel@surriel.com> (raw)
In-Reply-To: <20260611074344.GG48970@noisy.programming.kicks-ass.net>
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.
next prev parent reply other threads:[~2026-06-11 16:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 2:14 [PATCH 0/9] sched: make WARN_ON under rq->lock deadlock-safe (SCHED_WARN_ON) Rik van Riel
2026-06-11 2:14 ` [PATCH 1/9] sched: add SCHED_WARN_ON()/SCHED_WARN_ON_ONCE()/SCHED_WARN()/SCHED_WARN_ONCE() Rik van Riel
2026-06-11 2:14 ` [PATCH 2/9] sched/core: defer WARN console output under rq->lock Rik van Riel
2026-06-11 2:14 ` [PATCH 3/9] sched/fair: " Rik van Riel
2026-06-11 2:14 ` [PATCH 4/9] sched/deadline: " Rik van Riel
2026-06-11 2:14 ` [PATCH 5/9] sched/rt: " Rik van Riel
2026-06-11 2:14 ` [PATCH 6/9] sched_ext: " Rik van Riel
2026-06-11 2:14 ` [PATCH 7/9] sched/core_sched: " Rik van Riel
2026-06-11 2:14 ` [PATCH 8/9] sched/deadline: " Rik van Riel
2026-06-11 2:14 ` [PATCH 9/9] sched/rt: " Rik van Riel
2026-06-11 7:43 ` [PATCH 0/9] sched: make WARN_ON under rq->lock deadlock-safe (SCHED_WARN_ON) Peter Zijlstra
2026-06-11 16:20 ` Rik van Riel [this message]
2026-06-11 19:19 ` Peter Zijlstra
2026-06-12 1:53 ` Rik van Riel
2026-06-12 6:52 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc61cec71c284361882b5cc19f8520e2e85ec133.camel@surriel.com \
--to=riel@surriel.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox