kernel/arch/s390/include/asm/bug.h, branch linux-rolling-stable

s390/bug: Add missing alignment

2025-12-08T14:42:41Z

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:36Z

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:07Z

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:43Z

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

bugs/s390: Pass in 'cond_str' to __EMIT_BUG()

2025-07-28T06:01:56Z

Pass in the condition string from __WARN_FLAGS(), but do not concatenate it with __FILE__, because it results in s390 assembler build errors that are beyond my s390-asm-fu. Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Cc: Linus Torvalds Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: linux-s390@vger.kernel.org Cc: Link: https://lore.kernel.org/r/20250515124644.2958810-11-mingo@kernel.org

bugs/core: Extend __WARN_FLAGS() with the 'cond_str' parameter

2025-06-13T08:20:52Z

Push the new parameter down into every architecture that defines __WARN_FLAGS(): arm64 loongarch parisc powerpc riscv s390 sh x86 Don't pass anything substantial down yet, just propagate the new parameter with empty strings, without generating it or using it. ( The string is never NULL, so it can be concatenated at the preprocessor level. ) Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Cc: Linus Torvalds Cc: linux-arch@vger.kernel.org Link: https://lore.kernel.org/r/20250515124644.2958810-2-mingo@kernel.org

s390/bug: remove entry size from __bug_table section

2024-02-14T12:50:53Z

Commit e21f8baf8d9a ("s390/bug: add entry size to the __bug_table section") changed the __EMIT_BUG() inline assembly to emit mergeable __bug_table entries. This is at least currently not needed, but causes problems with the upcoming s390 ld.lld support: ld.lld: error: drivers/nvme/host/fc.o:(__bug_table): writable SHF_MERGE section is not supported Therefore revert the change for now. Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/all/20240207-s390-lld-and-orphan-warn-v1-0-8a665b3346ab@kernel.org/ Suggested-by: Nathan Chancellor Reviewed-by: Nathan Chancellor Signed-off-by: Heiko Carstens

bug: Use normal relative pointers in 'struct bug_entry'

2022-05-19T21:46:10Z

With CONFIG_GENERIC_BUG_RELATIVE_POINTERS, the addr/file relative pointers are calculated weirdly: based on the beginning of the bug_entry struct address, rather than their respective pointer addresses. Make the relative pointers less surprising to both humans and tools by calculating them the normal way. Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Mark Rutland Acked-by: Peter Zijlstra (Intel) Acked-by: Sven Schnelle # s390 Acked-by: Michael Ellerman (powerpc) Acked-by: Catalin Marinas Tested-by: Mark Rutland [arm64] Link: https://lkml.kernel.org/r/f0e05be797a16f4fc2401eeb88c8450dcbe61df6.1652362951.git.jpoimboe@kernel.org

printk: Make linux/printk.h self-contained

2020-07-27T08:46:24Z

As it stands if you include printk.h by itself it will fail to compile because it requires definitions from ratelimit.h. However, simply including ratelimit.h from printk.h does not work due to inclusion loops involving sched.h and kernel.h. This patch solves this by moving bits from ratelimit.h into a new header file which can then be included by printk.h without any worries about header loops. The build bot then revealed some intriguing failures arising out of this patch. On s390 there is an inclusion loop with asm/bug.h and linux/kernel.h that triggers a compile failure, because kernel.h will cause asm-generic/bug.h to be included before s390's own asm/bug.h has finished processing. This has been fixed by not including kernel.h in arch/s390/include/asm/bug.h. Signed-off-by: Herbert Xu Reviewed-by: Andy Shevchenko Reviewed-by: Sergey Senozhatsky Acked-by: Petr Mladek Acked-by: Steven Rostedt (VMware) Signed-off-by: Sergey Senozhatsky Link: https://lore.kernel.org/r/20200721062248.GA18383@gondor.apana.org.au

s390: fix __EMIT_BUG() macro

2020-01-22T12:05:35Z

Setting a kprobe on getname_flags() failed: $ echo 'p:tmr1 getname_flags +0(%r2):ustring' > kprobe_events -bash: echo: write error: Invalid argument Debugging the kprobes code showed that the address of getname_flags() is contained in the __bug_table. Kprobes doesn't allow to set probes at BUG() locations. $ objdump -j __bug_table -x build/fs/namei.o [..] 0000000000000108 R_390_PC32 .text+0x00000000000075a8 000000000000010c R_390_PC32 .L223+0x0000000000000004 I was expecting getname_flags() to start with a BUG(), but: 7598: e3 20 10 00 00 04 lg %r2,0(%r1) 759e: c0 f4 00 00 00 00 jg 759e 75a0: R_390_PLT32DBL kmem_cache_free+0x2 75a4: a7 f4 00 01 j 75a6 00000000000075a8 : 75a8: c0 04 00 00 00 00 brcl 0,75a8 75ae: eb 6f f0 48 00 24 stmg %r6,%r15,72(%r15) 75b4: b9 04 00 ef lgr %r14,%r15 75b8: e3 f0 ff a8 ff 71 lay %r15,-88(%r15) So the BUG() is actually the last opcode of the previous function. Fix this by switching to using the MONITOR CALL (MC) instruction, and set the entry in __bug_table to the beginning of that MC. Reviewed-by: Heiko Carstens Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik