[v1] Improve WARN_ON_ONCE() output by adding the condition string

[PATCH 0/5] Improve WARN_ON_ONCE() output by adding the condition string

Posted by Ingo Molnar 8 months, 4 weeks ago

This series improves the current WARN_ON_ONCE() output from:

  WARN_ON_ONCE(idx < 0 && ptr);
  ...

  WARNING: CPU: 0 PID: 0 at kernel/sched/core.c:8511 sched_init+0x20/0x410
  CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.14.0-01616-g94d7af2844aa #4 PREEMPT(undef)

to (on x86):

  WARNING: [idx < 0 && ptr] kernel/sched/core.c:8511 sched_init+0x20/0x410
  CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.14.0-01616-g94d7af2844aa #4 PREEMPT(undef)

and on non-x86 architectures (the CPU/PID fields in the WARNING line are skipped):

  WARNING: kernel/sched/core.c:8511 sched_init+0x20/0x410
  CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.14.0-01616-g94d7af2844aa #4 PREEMPT(undef)

The motivation is the SCHED_WARN_ON() primitive that got removed in this
merge window:

  f7d2728cc032 ("sched/debug: Change SCHED_WARN_ON() to WARN_ON_ONCE()")

... which produced more informative debug output, as it included the
WARN_ON_ONCE() condition string - at the expense of worse code generation.

This series, based on Linus's latest Git tree, merges the code generation
benefits of modern WARN_ON_ONCE() bug_entry architecture code with the expanded
information content of SCHED_WARN_ON().

The cost is about +100K more .data on a defconfig kernel, and no runtime
code generation impact:

       text       data        bss         dec        hex    filename
   29523998    7926322    1389904    38840224    250a7a0    vmlinux.x86.defconfig.before
   29523998    8024626    1389904    38938528    25227a0    vmlinue.x86.defconfig.after

The series was build and boot tested on x86, with an expectation for it to
work on other architectures (with no testing at the moment to back up that
expectation).

Thanks,

    Ingo

================>
Ingo Molnar (5):
  bugs/core: Extend __WARN_FLAGS() with the 'cond_str' parameter
  bugs/core: Pass down the condition string of WARN_ON_ONCE(cond) warnings to __WARN_FLAGS()
  bugs/x86: Extend _BUG_FLAGS() with the 'cond_str' parameter
  bugs/x86: Augment warnings output by concatenating 'cond_str' with the regular __FILE__ string in _BUG_FLAGS()
  bugs/core: Do not print CPU and PID values in__warn() output

 arch/arm64/include/asm/bug.h     |  2 +-
 arch/loongarch/include/asm/bug.h |  2 +-
 arch/parisc/include/asm/bug.h    |  4 ++--
 arch/powerpc/include/asm/bug.h   |  2 +-
 arch/riscv/include/asm/bug.h     |  2 +-
 arch/s390/include/asm/bug.h      |  2 +-
 arch/sh/include/asm/bug.h        |  2 +-
 arch/x86/include/asm/bug.h       | 14 +++++++-------
 include/asm-generic/bug.h        |  7 ++++---
 kernel/panic.c                   |  7 ++-----
 10 files changed, 21 insertions(+), 23 deletions(-)

-- 
2.45.2

Re: [PATCH 0/5] Improve WARN_ON_ONCE() output by adding the condition string

Posted by Rasmus Villemoes 8 months, 3 weeks ago

On Wed, Mar 26 2025, Ingo Molnar <mingo@kernel.org> wrote:

> The cost is about +100K more .data on a defconfig kernel, and no runtime
> code generation impact:
>
>        text       data        bss         dec        hex    filename
>    29523998    7926322    1389904    38840224    250a7a0    vmlinux.x86.defconfig.before
>    29523998    8024626    1389904    38938528    25227a0    vmlinue.x86.defconfig.after
>

That's quite a lot. I don't suppose the condition strings themselves are
responsible for most of that; how much is due to the __FILE__ strings
now no longer being deduplicated/shared between WARN instances in same
file? How much harder would it be to add a new cond_str member to
bug_entry, and how would the numbers look then?

Rasmus