kernel/arch/s390/boot/Makefile, branch linux-rolling-stable

s390/boot: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGS

2026-03-04T12:19:35Z

[ Upstream commit 5ba35a6c13fff0929c34aba6b7602dacbe68686c ] Add -Wno-default-const-init-unsafe to boot KBUILD_CFLAGS, similar to scripts/Makefile.extrawarn, since clang generates warnings for the dummy variable in typecheck(): CC arch/s390/boot/version.o arch/s390/include/asm/ptrace.h:221:9: warning: default initialization of an object of type 'typeof (regs->psw)' (aka 'const psw_t') leaves the object uninitialized [-Wdefault-const-init-var-unsafe] 221 | return psw_bits(regs->psw).pstate; | ^ arch/s390/include/asm/ptrace.h:98:2: note: expanded from macro 'psw_bits' 98 | typecheck(psw_t, __psw); \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390: Add stackprotector support

2025-11-24T10:45:21Z

Stackprotector support was previously unavailable on s390 because by default compilers generate code which is not suitable for the kernel: the canary value is accessed via thread local storage, where the address of thread local storage is within access registers 0 and 1. Using those registers also for the kernel would come with a significant performance impact and more complicated kernel entry/exit code, since access registers contents would have to be exchanged on every kernel entry and exit. With the upcoming gcc 16 release new compiler options will become available which allow to generate code suitable for the kernel. [1] Compiler option -mstack-protector-guard=global instructs gcc to generate stackprotector code that refers to a global stackprotector canary value via symbol __stack_chk_guard. Access to this value is guaranteed to occur via larl and lgrl instructions. Furthermore, compiler option -mstack-protector-guard-record generates a section containing all code addresses that reference the canary value. To allow for per task canary values the instructions which load the address of __stack_chk_guard are patched so they access a lowcore field instead: a per task canary value is available within the task_struct of each task, and is written to the per-cpu lowcore location on each context switch. Also add sanity checks and debugging option to be consistent with other kernel code patching mechanisms. Full debugging output can be enabled with the following kernel command line options: debug_stackprotector bootdebug ignore_loglevel earlyprintk dyndbg="file stackprotector.c +p" Example debug output: stackprot: 0000021e402d4eda: c010005a9ae3 -> c01f00070240 where ": -> ". [1] gcc commit 0cd1f03939d5 ("s390: Support global stack protector") Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/boot: Introduce jump_to_kernel() function

2025-07-10T12:42:10Z

Introduce a global function that jumps from the decompressor to the decompressed kernel. Put its address into svc_old_psw, from where GDB can take it without loading decompressor symbols. It should be available throughout the entire decompressor execution, because it's placed there statically, and nothing in the decompressor uses the SVC instruction. Acked-by: Heiko Carstens Signed-off-by: Ilya Leoshkevich Tested-by: Alexander Gordeev Link: https://lore.kernel.org/r/20250625154220.75300-2-iii@linux.ibm.com Signed-off-by: Alexander Gordeev

s390/boot: Use -D__DISABLE_EXPORTS

2025-06-25T10:25:56Z

Files in the arch/s390/boot directory reuse logic from the rest of the kernel by including certain C and assembly files from the kernel and lib directories. Some of these included files contain EXPORT_SYMBOL directives. For instance, arch/s390/boot/cmdline.c includes lib/cmdline.c, which exports the get_option() function. This inclusion triggers genksyms processing for the files in arch/s390/boot, which is unnecessary and slows down the build. Additionally, when KBUILD_SYMTYPES=1 is set, the generated symtypes data contain exported symbols that are duplicated with the main kernel. This duplication can confuse external kABI tools that process the symtypes data. Address this issue by compiling the files in arch/s390/boot with -D__DISABLE_EXPORTS. Signed-off-by: Petr Pavlu Reviewed-by: Heiko Carstens Link: https://lore.kernel.org/r/20250620154649.116068-1-petr.pavlu@suse.com Signed-off-by: Alexander Gordeev

s390/boot: Add exception table support

2025-03-04T16:25:22Z

The early boot code contains various open-coded inline assemblies with exception handling. In order to handle possible exceptions each of them changes the program check new psw, and restores it. In order to simplify the various inline assemblies add simple exception table support: the program check handler is called with a fully populated pt_regs on the stack and may change the psw and register members. When the program check handler returns the psw and registers from pt_regs will be used to continue execution. The program check handler searches the exception table for an entry which matches the address of the program check. If such an entry is found the psw address within pt_regs on the stack is replaced with a fixup address, and execution continues at the new address. If no entry is found the psw is changed to a disabled wait psw and execution stops. Before entering the C part of the program check handler the address of the program check new psw is replaced to a minimalistic handler. This is supposed to help against program check loops. If an exception happens while in program check processing the register contents of the original exception are restored and a disabled wait psw is loaded. Acked-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik

s390/boot: Move boot_printk() code to own file

2024-09-07T15:12:43Z

Keep the printk code separate from the program check code and move boot_printk() and helper functions to own printk.c file. Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/boot: Compile all files with the same march flag

2024-09-07T15:12:42Z

Only a couple of files of the decompressor are compiled with the minimum architecture level. This is problematic for potential function calls between compile units, especially if a target function is within a compile until compiled for a higher architecture level, since that may lead to an unexpected operation exception. Therefore compile all files of the decompressor for the same (minimum) architecture level. Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/boot: Increase minimum architecture to z10

2024-09-07T15:12:42Z

The decompressor code is partially compiled with march=z900 so it is possible to print an error message in case a kernel is booted on a machine which misses facilities to execute the kernel. Given that the decompressor code also includes header files from the core kernel this causes problems for inline assemblies and other code where the minimum assumed architecture level is set to z10 in the meantime. If such code is also used in the decompressor (e.g. inline functions) z900 support must be implemented again. In order to avoid this and to keep things simple just raise the minimum architecture level to z10 for the decompressor just like for the kernel. Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens

s390/build: Avoid relocation information in final vmlinux

2024-08-27T18:16:48Z

Since commit 778666df60f0 ("s390: compile relocatable kernel without -fPIE") the kernel vmlinux ELF file is linked with --emit-relocs to preserve all relocations, so that all absolute relocations can be extracted using the 'relocs' tool to adjust them during boot. Port and adapt Petr Pavlu's x86 commit 9d9173e9ceb6 ("x86/build: Avoid relocation information in final vmlinux") to s390 to strip all relocations from the final vmlinux ELF file to optimize its size. Following is his original commit message with minor adaptions for s390: The Linux build process on s390 roughly consists of compiling all input files, statically linking them into a vmlinux ELF file, and then taking and turning this file into an actual bzImage bootable file. vmlinux has in this process two main purposes: 1) It is an intermediate build target on the way to produce the final bootable image. 2) It is a file that is expected to be used by debuggers and standard ELF tooling to work with the built kernel. For the second purpose, a vmlinux file is typically collected by various package build recipes, such as distribution spec files, including the kernel's own tar-pkg target. When building the kernel vmlinux contains also relocation information produced by using the --emit-relocs linker option. This is utilized by subsequent build steps to create relocs.S and produce a relocatable image. However, the information is not needed by debuggers and other standard ELF tooling. The issue is then that the collected vmlinux file and hence distribution packages end up unnecessarily large because of this extra data. The following is a size comparison of vmlinux v6.10 with and without the relocation information: | Configuration | With relocs | Stripped relocs | | defconfig | 696 MB | 320 MB | | -CONFIG_DEBUG_INFO | 48 MB | 32 MB | Optimize a resulting vmlinux by adding a postlink step that splits the relocation information into relocs.S and then strips it from the vmlinux binary. Reviewed-by: Vasily Gorbik Signed-off-by: Jens Remus Signed-off-by: Vasily Gorbik

s390: Remove protvirt and kvm config guards for uv code

2024-07-23T14:02:33Z

Removing the CONFIG_PROTECTED_VIRTUALIZATION_GUEST ifdefs and config option as well as CONFIG_KVM ifdefs in uv files. Having this configurable has been more of a pain than a help. It's time to remove the ifdefs and the config option. Signed-off-by: Janosch Frank Acked-by: Christian Borntraeger Acked-by: Heiko Carstens Signed-off-by: Vasily Gorbik