From nobody Fri Dec 19 00:33:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3BCC279F5; Tue, 25 Mar 2025 11:18:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742901525; cv=none; b=Ji6QM2JYcjSyypCcN6ALRjz3Z2BOd95q2SVyx7QybAYFjb3i16ztWGc/fn0J+4kbHrauGBDsOx5/dxT6Xafp2ObgjCaUIAwsWAsYvPScNiUO36bMyBBsAqow6346mOxEDVnsAhXDXs+rCzpdrk8v31JM05U0fn5uJsel+gOqIkg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742901525; c=relaxed/simple; bh=khDMRd3/8spXHUnQOPT5netn3r10aLnbqLNTmcWzJTI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Z0GuTvo7mxkux+rsv5yoDuuqJI11H06mSac13ok9eLZutSpysOEO+7q8de6enhTDhLjgj6QuU5I3jJQGgetLKAW5kbi24AMAkqTiUKxlFon9Tnj4hC61GzVzjQ9V1JgVYT+/RItQlRXzt7BgJSOD66M3hay0PGbtjsmxmCOESCk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kukHuGM5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kukHuGM5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7EBBC4CEE4; Tue, 25 Mar 2025 11:18:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742901524; bh=khDMRd3/8spXHUnQOPT5netn3r10aLnbqLNTmcWzJTI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kukHuGM5kAqyY3WKu39GCJbJrhnZXwWq7xs4VeZzS55T3Nhv8Q64JBh0z2eUIZBgf mOyWh70ATo8x21lTO1V9gSgn28Kh4cgsGgucpYeMJcnUQ/NBm6XOvIZI/4Ks3n8y+s d0rhL4xRAZz3ct4S17EgQsC0j/hJolNZQCzZgShdAn6AuwTlSivv8SwAWRAlRADnJk iNjHcLXZFTNKOVnI5SnzwMdSuE2yseFSBMTesaP45kaGDwLqCLadZOuUnsVSEgkzfd 2mVmiYiJPdpqp/fh1sWInQ26WZ701weh5+x6PMqFqKx+Kazk40TbjWmriOEOGlqEfJ 4y94wDltOc6kA== Date: Tue, 25 Mar 2025 12:18:39 +0100 From: Ingo Molnar To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org, Shrikanth Hegde , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Linus Torvalds , x86@kernel.org Subject: [PATCH] bug: Introduce CONFIG_DEBUG_BUGVERBOSE_EXTRA=y to also log warning conditions Message-ID: References: <20250317104257.3496611-2-mingo@kernel.org> <174246120542.14745.16936293992221722909.tip-bot2@tip-bot2> <20250324115955.GF14944@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" * Ingo Molnar wrote: > > > #define SCHED_WARN_ON(x) WARN_ONCE(x, #x) > > >=20 > > > Because SCHED_WARN_ON() would output the 'x' condition > > > as well, while WARN_ONCE() will only show a backtrace. > > >=20 > > > Hopefully these are rare enough to not really matter. > > >=20 > > > If it does, we should probably introduce a new WARN_ON() > > > variant that outputs the condition in stringified form, > > > or improve WARN_ON() itself. > >=20 > > So those strings really were useful, trouble is WARN_ONCE() generates > > utter crap code compared to WARN_ON_ONCE(), but since SCHED_DEBUG that > > doesn't really matter. >=20 > Why wouldn't it matter? CONFIG_SCHED_DEBUG was turned on for 99.9999%=20 > of Linux users, ie. we generated crap code for most of our users. >=20 > And as a side effect of using the standard WARN_ON_ONCE() primitive we=20 > now generate better code, at the expense of harder to interpret debug=20 > output, right? >=20 > Ie. CONFIG_SCHED_DEBUG has obfuscated crappy code generation under the=20 > "it's only debugging code" pretense, right? So, to argue this via code, we'd like to have something like the patch belo= w? When enabled it will warn in the following fashion: static void super_perfect_kernel_function(void *ptr) { ... WARN_ON_ONCE(ptr =3D=3D 0 && 1); ... } ------------[ cut here ]------------ FAIL: 'ptr =3D=3D 0 && 1' is true WARNING: CPU: 0 PID: 0 at kernel/sched/core.c:8511 sched_init+0x44/0x430 ... But the real question is, how do we keep distros from enabling=20 CONFIG_DEBUG_BUGVERBOSE_EXTRA=3Dy? It does bloat the defconfig by about +144k .text and ~64k data, so=20 maybe that's deterrence enough. The BSS shift is due to it not using the clever x86 U2D tricks, right? Thanks, Ingo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> From: Ingo Molnar Date: Tue, 25 Mar 2025 11:35:20 +0100 Subject: [PATCH] bug: Introduce CONFIG_DEBUG_BUGVERBOSE_EXTRA=3Dy to also l= og warning conditions text data bss dec hex filename 29522704 7926322 1389904 38838930 250a292 vmlinux.before 29667392 8017958 1363024 39048374 253d4b6 vmlinux.after Totally-Not-Signed-off-by: Ingo Molnar --- include/asm-generic/bug.h | 7 +++++++ kernel/sched/core.c | 2 ++ lib/Kconfig.debug | 12 ++++++++++++ 3 files changed, 21 insertions(+) diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h index 387720933973..5475258a99dc 100644 --- a/include/asm-generic/bug.h +++ b/include/asm-generic/bug.h @@ -92,6 +92,11 @@ void warn_slowpath_fmt(const char *file, const int line,= unsigned taint, const char *fmt, ...); extern __printf(1, 2) void __warn_printk(const char *fmt, ...); =20 +#ifdef CONFIG_DEBUG_BUGVERBOSE_EXTRA +#define WARN_ON_ONCE(condition) \ + DO_ONCE_LITE_IF(condition, WARN, 1, "FAIL: '%s' is true", #condition) +#endif + #ifndef __WARN_FLAGS #define __WARN() __WARN_printf(TAINT_WARN, NULL) #define __WARN_printf(taint, arg...) do { \ @@ -107,6 +112,7 @@ extern __printf(1, 2) void __warn_printk(const char *fm= t, ...); __WARN_FLAGS(BUGFLAG_NO_CUT_HERE | BUGFLAG_TAINT(taint));\ instrumentation_end(); \ } while (0) +#ifndef WARN_ON_ONCE #define WARN_ON_ONCE(condition) ({ \ int __ret_warn_on =3D !!(condition); \ if (unlikely(__ret_warn_on)) \ @@ -115,6 +121,7 @@ extern __printf(1, 2) void __warn_printk(const char *fm= t, ...); unlikely(__ret_warn_on); \ }) #endif +#endif =20 /* used internally by panic.c */ =20 diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 87540217fc09..71bf94bf68f8 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -8508,6 +8508,8 @@ void __init sched_init(void) unsigned long ptr =3D 0; int i; =20 + WARN_ON_ONCE(ptr =3D=3D 0 && 1); + /* Make sure the linker didn't screw up */ #ifdef CONFIG_SMP BUG_ON(!sched_class_above(&stop_sched_class, &dl_sched_class)); diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index b1b92a9a8f24..88f215f712f8 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -206,6 +206,18 @@ config DEBUG_BUGVERBOSE of the BUG call as well as the EIP and oops trace. This aids debugging but costs about 70-100K of memory. =20 +config DEBUG_BUGVERBOSE_EXTRA + bool "Extra verbose WARN_ON() reporting" if DEBUG_BUGVERBOSE + default n + help + Say Y here to make WARN_ON() warnings extra verbose, printing + the condition they warn about. + + This aids debugging but uses up some memory and causes some + runtime overhead due to worse code generation. + + If unsure, say N. + endmenu # "printk and dmesg options" =20 config DEBUG_KERNEL