kernel/linux.git/arch/s390/include/asm/bug.h, branch v7.1

s390/bug: Always emit format word in __BUG_ENTRY

2026-05-28T10:08:27+00:00

When CONFIG_DEBUG_BUGVERBOSE is disabled, the s390 __BUG_ENTRY() macro omits the format string pointer, so the generated __bug_table entry no longer matches struct bug_entry. With HAVE_ARCH_BUG_FORMAT enabled, the generic BUG infrastructure reads bug_entry::format via bug_get_format(). If the format word is missing, subsequent fields are read from the wrong offset, which may: - Misinterpret flags (BUG vs WARN classification errors) - Fault when dereferencing a misread format pointer The root cause is that __BUG_ENTRY() delegates format word emission to __BUG_ENTRY_VERBOSE(), which is conditional on CONFIG_DEBUG_BUGVERBOSE. Fix this by moving the format field emission directly into __BUG_ENTRY() so it is always emitted unconditionally. Remove the format parameter from __BUG_ENTRY_VERBOSE() and keep only file/line emission conditional on CONFIG_DEBUG_BUGVERBOSE. Fixes: 2b71b8ab9718 ("s390/bug: Use BUG_FORMAT for DEBUG_BUGVERBOSE_DETAILED") Signed-off-by: Jan Polensky Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev

s390/bug: Prevent tail-call optimization

2026-01-27T11:16:16+00:00

For the exception based __WARN_trap() implementation it is technically not necessary to prevent tail-call optimization, however it may be confusing to see warning messages like: WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x2c/0x50, CPU#0: swapper/0/0 together with a disassembly of a different function caused by tail-call optimization for the __WARN_trap() call. Prevent that by adding an empty asm statement. This generates slightly worse code, but should hopefully avoid confusion. With this the output looks like: WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x2c/0x50, CPU#0: swapper/0/0 ... Krnl PSW : 0704c00180000000 000003ffe0119788 (foobar+0x38/0x50) ... Krnl Code: 000003ffe0119776: e3e0f0980024 stg %r14,152(%r15) 000003ffe011977c: c02000b8992a larl %r2,000003ffe182c9d0 *000003ffe0119782: c0e5007270b7 brasl %r14,000003ffe0f678f0 >000003ffe0119788: ebeff0a00004 lmg %r14,%r15,160(%r15) 000003ffe011978e: 07fe bcr 15,%r14 000003ffe0119790: 47000700 bc 0,1792 000003ffe0119794: 0707 bcr 0,%r7 000003ffe0119796: 0707 bcr 0,%r7 Call Trace: [<000003ffe0119788>] foobar+0x38/0x50 [<000003ffe185bc2e>] arch_cpu_finalize_init+0x26/0x60 [<000003ffe185654c>] start_kernel+0x53c/0x5d8 [<000003ffe010002e>] startup_continue+0x2e/0x40 A better solution would be to replace or patch the branch instruction to __WARN_trap() with the monitor call instruction, similar to what is done for x86 [1]. However s390 does not support static_cond_calls(). Therefore use the simple approach for the time being. [1] commit 860238af7a33 ("x86_64/bug: Inline the UD1") Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/bug: Implement WARN_ONCE()

2026-01-27T11:16:16+00:00

This is the s390 variant of commit 11bb4944f014 ("x86/bug: Implement WARN_ONCE()"). Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/bug: Implement __WARN_printf()

2026-01-27T11:16:16+00:00

This is the s390 variant of commit 5b472b6e5bd9 ("x86_64/bug: Implement __WARN_printf()"). See the x86 commit for the general idea; there are only implementation details which are different. With the new exception based __WARN_printf() implementation the generated code for a simple WARN() is simplified. For example: void foo(int a) { WARN(a, "bar"); } Before this change the generated code looks like this: 0000000000000210 : 210: c0 04 00 00 00 00 jgnop 210 216: ec 26 00 06 00 7c cgijne %r2,0,222 21c: c0 f4 00 00 00 00 jg 21c 21e: R_390_PC32DBL __s390_indirect_jump_r14+0x2 222: eb ef f0 88 00 24 stmg %r14,%r15,136(%r15) 228: b9 04 00 ef lgr %r14,%r15 22c: e3 f0 ff e8 ff 71 lay %r15,-24(%r15) 232: e3 e0 f0 98 00 24 stg %r14,152(%r15) 238: c0 20 00 00 00 00 larl %r2,238 23a: R_390_PC32DBL .LC48+0x2 23e: c0 e5 00 00 00 00 brasl %r14,23e 240: R_390_PLT32DBL __warn_printk+0x2 244: af 00 00 00 mc 0,0 248: eb ef f0 a0 00 04 lmg %r14,%r15,160(%r15) 24e: c0 f4 00 00 00 00 jg 24e 250: R_390_PC32DBL __s390_indirect_jump_r14+0x2 With this change the generated code looks like this: 0000000000000210 : 210: c0 04 00 00 00 00 jgnop 210 216: ec 26 00 06 00 7c cgijne %r2,0,222 21c: c0 f4 00 00 00 00 jg 21c 21e: R_390_PC32DBL __s390_indirect_jump_r14+0x2 222: c0 20 00 00 00 00 larl %r2,222 224: R_390_PC32DBL __bug_table+0x2 228: c0 f4 00 00 00 00 jg 228 22a: R_390_PLT32DBL __WARN_trap+0x2 Downside is that the call trace now starts at __WARN_trap(): ------------[ cut here ]------------ bar WARNING: arch/s390/kernel/setup.c:1017 at 0x0, CPU#0: swapper/0/0 ... Krnl PSW : 0704c00180000000 000003ffe0f6a3b4 (__WARN_trap+0x4/0x10) ... Krnl Code: 000003ffe0f6a3ac: 0707 bcr 0,%r7 000003ffe0f6a3ae: 0707 bcr 0,%r7 *000003ffe0f6a3b0: af000001 mc 1,0 >000003ffe0f6a3b4: 07fe bcr 15,%r14 000003ffe0f6a3b6: 47000700 bc 0,1792 000003ffe0f6a3ba: 0707 bcr 0,%r7 000003ffe0f6a3bc: 0707 bcr 0,%r7 000003ffe0f6a3be: 0707 bcr 0,%r7 Call Trace: [<000003ffe0f6a3b4>] __WARN_trap+0x4/0x10 ([<000003ffe185a54c>] start_kernel+0x53c/0x5d8) [<000003ffe010002e>] startup_continue+0x2e/0x40 Which isn't too helpful. This can be addressed by just skipping __WARN_trap(), which will be addressed in a later patch. Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/bug: Introduce and use monitor code macro

2026-01-27T11:16:16+00:00

The first operand address of the monitor call (mc) instruction is the monitor code. Currently the monitor code is ignored, but this will change. Therefore add and use MONCODE_BUG instead of a hardcoded zero. Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/bug: Use BUG_FORMAT for DEBUG_BUGVERBOSE_DETAILED

2026-01-27T11:16:15+00:00

This is just the s390 variant of commit 4f1b701f24be ("x86/bug: Use BUG_FORMAT for DEBUG_BUGVERBOSE_DETAILED"). Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/bug: Convert to inline assembly with input operands

2026-01-27T11:16:15+00:00

Rewrite the bug inline assembly so it uses input operands again instead of pure macro replacements. This more or less reverts the conversion done when 'cond_str' support was added [1]. Reason for this is that the upcoming __WARN_printf() implementation requires an inline assembly with an output operand. At the same time input strings (format specifier and condition string) may contain the special '%' character. As soon as an inline assembly is specified to have input/output operands the '%' has a special meaning: e.g. converting the existing #define __BUG_FLAGS(cond_str, flags) \ asm_inline volatile(__stringify(ASM_BUG_FLAGS(cond_str, flags))); to #define __BUG_FLAGS(cond_str, flags) \ asm_inline volatile(__stringify(ASM_BUG_FLAGS(cond_str, flags))::); will result in a compile error as soon as 'cond_str' contains a '%' character: net/core/neighbour.c: In function ‘neigh_table_init’: ././include/linux/compiler_types.h:546:20: error: invalid 'asm': invalid %-code ... net/core/neighbour.c:1838:17: note: in expansion of macro ‘WARN_ON’ 1838 | WARN_ON(tbl->entry_size % NEIGH_PRIV_ALIGN); | ^~~~~~~ Convert the code, use immediate operands, and also add comments similar to x86 which are emitted to the generated assembly file, which makes debugging much easier. Note: since gcc-8 does not support strings as immediate input operands, guard the new implementation with CC_HAS_ASM_IMMEDIATE_STRINGS and fallback to the generic non-exception based warning implementation for incompatible compilers. [1] 6584ff203aec ("bugs/s390: Use 'cond_str' in __EMIT_BUG()") Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/bug: Add missing alignment

2025-12-08T14:42:41+00:00

All objects are supposed to have a minimal alignment of two, since a couple of instructions only work with even addresses. Add the missing align statement for the file string. Fixes: 6584ff203aec ("bugs/s390: Use 'cond_str' in __EMIT_BUG()") Signed-off-by: Heiko Carstens

s390/bug: Add missing CONFIG_BUG ifdef again

2025-12-08T14:42:36+00:00

Fallback to generic BUG implementation in case CONFIG_BUG is disabled. This restores the old behaviour before 'cond_str' support was added. It probably doesn't matter, since nobody should disable CONFIG_BUG, but at least this is consistent to before. Fixes: 6584ff203aec ("bugs/s390: Use 'cond_str' in __EMIT_BUG()") Signed-off-by: Heiko Carstens

bugs/s390: Remove private WARN_ON() implementation

2025-07-28T06:07:07+00:00

Besides an odd __builtin_constant_p() optimization the s390 specific WARN_ON() implementation is identical to the generic variant. Drop the s390 variant in favor of the generic variant. Signed-off-by: Heiko Carstens Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar # Rebased ancestor commits Reviewed-by: Alexander Gordeev Link: https://lore.kernel.org/r/20250617135042.1878068-2-hca@linux.ibm.com