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

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

bugs/s390: Use 'cond_str' in __EMIT_BUG()

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

The simple thing would be to add the string as an assembly immediate input operand. Some older gcc variants cannot handle strings as immediate input operands for inline assemblies. Doing so may result in compile errors. Rewrite the s390 generic bug support very similar to arm64 and loongarch, and get rid of all input operands to fix this. [ peterz: backmerge fix and massage changelog ] [ bp: clang integrated assembler concatenates only .ascii strings: https://lore.kernel.org/r/202507020528.N0LtekXt-lkp@intel.com ] Signed-off-by: Heiko Carstens Signed-off-by: Ingo Molnar Signed-off-by: Peter Zijlstra Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar # Fixed the tags section Acked-by: Alexander Gordeev Cc: Linus Torvalds Cc: linux-arch@vger.kernel.org Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: Sven Schnelle Cc: linux-s390@vger.kernel.org Link: https://lore.kernel.org/r/20250520133927.7932C19-hca@linux.ibm.com Link: https://lore.kernel.org/r/20250617135042.1878068-3-hca@linux.ibm.com