linux-kernel - Re: [PATCH 2/2] Fix SCHED_WARN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251028184537.GC3419281@noisy.programming.kicks-ass.net>
Date: Tue, 28 Oct 2025 19:45:37 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Bart Van Assche <bvanassche@....org>
Cc: Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH 2/2] Fix SCHED_WARN_ON()

On Tue, Oct 28, 2025 at 09:50:58AM -0700, Bart Van Assche wrote:
> SCHED_WARN_ON() uses WARN_ONCE() and WARN_ONCE() uses printk(). Using
> printk() from certain code paths in the process scheduler is not allowed
> because printk() acquires the console_lock and this may cause printk()
> to sleep. Sleeping is not allowed from many paths in the process
> scheduler. Hence make sure that SCHED_WARN_ON() uses printk_deferred()
> instead of printk().

Yeah, so no. I hate that deferred thing with a passion. It means your
warning will never make it out if something fatal happens.

The printk() people have been working on fixing this for a long while
and I think they're close. All the crap consoles will get threaded
printing while the useful consoles (serial) will get atomic printing.

Also, you should never hit these WARNs to begin with, and if you do,
that lockdep splat is the least of your problems.