Changes in Makefile

90d7412cd1ca82528adaf79abffaf12c36ba1b19 - s390/string: Convert memset(16|32|64)() to C

Tue, 09 Jun 2026 12:33:41 +0200

s390/string: Convert memset(16|32|64)() to CConvert memset(16|32|64)() from assembler to C, which should make iteasier to read and change, if required. And it allows the compiler tooptimize the code, and use different instructions, except for the usedinline assemblies.Reviewed-by: Juergen Christ Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev List of files: /linux/arch/s390/boot/Makefile

78016b6da77e9d3a5ed11f7366cac385eb50a058 - s390/string: Add -ffreestanding compile option to string.o

Tue, 09 Jun 2026 12:33:37 +0200

s390/string: Add -ffreestanding compile option to string.oUse -ffreestanding for string.o to avoid that the compiler generatescalls into themselves for standard library functions like memset().Reviewed-by: Juergen Christ Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev List of files: /linux/arch/s390/boot/Makefile

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

Fri, 12 Dec 2025 16:43:58 +0100

s390/boot: Add -Wno-default-const-init-unsafe to KBUILD_CFLAGSAdd -Wno-default-const-init-unsafe to boot KBUILD_CFLAGS, similar toscripts/Makefile.extrawarn, since clang generates warnings for the dummyvariable 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 List of files: /linux/arch/s390/boot/Makefile

f5730d44e05efb43a5cb64e5eb04e24994bbb50f - s390: Add stackprotector support

Mon, 17 Nov 2025 15:09:53 +0100

s390: Add stackprotector supportStackprotector support was previously unavailable on s390 because bydefault compilers generate code which is not suitable for the kernel:the canary value is accessed via thread local storage, where the addressof thread local storage is within access registers 0 and 1.Using those registers also for the kernel would come with a significantperformance impact and more complicated kernel entry/exit code, sinceaccess registers contents would have to be exchanged on every kernel entryand exit.With the upcoming gcc 16 release new compiler options will become availablewhich allow to generate code suitable for the kernel. [1]Compiler option -mstack-protector-guard=global instructs gcc to generatestackprotector code that refers to a global stackprotector canary value viasymbol __stack_chk_guard. Access to this value is guaranteed to occur vialarl and lgrl instructions.Furthermore, compiler option -mstack-protector-guard-record generates asection containing all code addresses that reference the canary value.To allow for per task canary values the instructions which load the addressof __stack_chk_guard are patched so they access a lowcore field instead: aper task canary value is available within the task_struct of each task, andis written to the per-cpu lowcore location on each context switch.Also add sanity checks and debugging option to be consistent with otherkernel code patching mechanisms.Full debugging output can be enabled with the following kernel command lineoptions:debug_stackprotectorbootdebugignore_loglevelearlyprintkdyndbg="file stackprotector.c +p"Example debug output:stackprot: 0000021e402d4eda: c010005a9ae3 -> c01f00070240where ": -> ".[1] gcc commit 0cd1f03939d5 ("s390: Support global stack protector")Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens List of files: /linux/arch/s390/boot/Makefile

996f7f292b7e190138738bd9213616a544837a41 - s390/boot: Introduce jump_to_kernel() function

Wed, 25 Jun 2025 17:36:51 +0200

s390/boot: Introduce jump_to_kernel() functionIntroduce a global function that jumps from the decompressor to thedecompressed kernel. Put its address into svc_old_psw, from where GDBcan take it without loading decompressor symbols. It should beavailable throughout the entire decompressor execution, because it'splaced there statically, and nothing in the decompressor uses the SVCinstruction.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.comSigned-off-by: Alexander Gordeev List of files: /linux/arch/s390/boot/Makefile

819275e18112f682d9ca9b66190fc714a2910a53 - s390/boot: Use -D__DISABLE_EXPORTS

Fri, 20 Jun 2025 17:45:49 +0200

s390/boot: Use -D__DISABLE_EXPORTSFiles in the arch/s390/boot directory reuse logic from the rest of thekernel by including certain C and assembly files from the kernel and libdirectories. Some of these included files contain EXPORT_SYMBOL directives.For instance, arch/s390/boot/cmdline.c includes lib/cmdline.c, whichexports the get_option() function.This inclusion triggers genksyms processing for the files inarch/s390/boot, which is unnecessary and slows down the build.Additionally, when KBUILD_SYMTYPES=1 is set, the generated symtypes datacontain exported symbols that are duplicated with the main kernel. Thisduplication 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.comSigned-off-by: Alexander Gordeev List of files: /linux/arch/s390/boot/Makefile

6067891b65cbf0068c2266d40a3a67df8535f72c - s390/boot: Add exception table support

Mon, 24 Feb 2025 15:59:05 +0100

s390/boot: Add exception table supportThe early boot code contains various open-coded inline assemblies withexception handling. In order to handle possible exceptions each of themchanges the program check new psw, and restores it.In order to simplify the various inline assemblies add simple exceptiontable support: the program check handler is called with a fully populatedpt_regs on the stack and may change the psw and register members. When theprogram check handler returns the psw and registers from pt_regs will beused to continue execution.The program check handler searches the exception table for an entry whichmatches the address of the program check. If such an entry is found the pswaddress within pt_regs on the stack is replaced with a fixup address, andexecution continues at the new address.If no entry is found the psw is changed to a disabled wait psw andexecution stops.Before entering the C part of the program check handler the address of theprogram check new psw is replaced to a minimalistic handler.This is supposed to help against program check loops. If an exceptionhappens while in program check processing the register contents of theoriginal exception are restored and a disabled wait psw is loaded.Acked-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik List of files: /linux/arch/s390/boot/Makefile

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

Wed, 04 Sep 2024 11:39:30 +0200

s390/boot: Move boot_printk() code to own fileKeep the printk code separate from the program check code and moveboot_printk() and helper functions to own printk.c file.Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens List of files: /linux/arch/s390/boot/Makefile

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

Wed, 04 Sep 2024 11:39:27 +0200

s390/boot: Compile all files with the same march flagOnly a couple of files of the decompressor are compiled with theminimum architecture level. This is problematic for potential functioncalls between compile units, especially if a target function is withina compile until compiled for a higher architecture level, since thatmay 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 List of files: /linux/arch/s390/boot/Makefile

db545f5387472176cf1e7df76fe97a4f56b7158d - s390/boot: Increase minimum architecture to z10

Wed, 04 Sep 2024 11:39:23 +0200

s390/boot: Increase minimum architecture to z10The decompressor code is partially compiled with march=z900 so it ispossible to print an error message in case a kernel is booted on amachine which misses facilities to execute the kernel.Given that the decompressor code also includes header files from thecore kernel this causes problems for inline assemblies and other codewhere the minimum assumed architecture level is set to z10 in themeantime. If such code is also used in the decompressor (e.g. inlinefunctions) z900 support must be implemented again.In order to avoid this and to keep things simple just raise theminimum architecture level to z10 for the decompressor just like forthe kernel.Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens List of files: /linux/arch/s390/boot/Makefile

57216cc985b34c4cd6107a15fb04ca881465176d - s390/build: Avoid relocation information in final vmlinux

Thu, 22 Aug 2024 17:30:21 +0200

s390/build: Avoid relocation information in final vmlinuxSince commit 778666df60f0 ("s390: compile relocatable kernel without-fPIE") the kernel vmlinux ELF file is linked with --emit-relocs topreserve all relocations, so that all absolute relocations can beextracted using the 'relocs' tool to adjust them during boot.Port and adapt Petr Pavlu's x86 commit 9d9173e9ceb6 ("x86/build: Avoidrelocation information in final vmlinux") to s390 to strip allrelocations 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 inputfiles, statically linking them into a vmlinux ELF file, and then takingand 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 variouspackage build recipes, such as distribution spec files, including thekernel's own tar-pkg target.When building the kernel vmlinux contains also relocation informationproduced by using the --emit-relocs linker option. This is utilized bysubsequent build steps to create relocs.S and produce a relocatableimage. However, the information is not needed by debuggers and otherstandard ELF tooling.The issue is then that the collected vmlinux file and hence distributionpackages end up unnecessarily large because of this extra data. Thefollowing is a size comparison of vmlinux v6.10 with and without therelocation 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 therelocation information into relocs.S and then strips it from the vmlinuxbinary.Reviewed-by: Vasily Gorbik Signed-off-by: Jens Remus Signed-off-by: Vasily Gorbik List of files: /linux/arch/s390/boot/Makefile

6dc2e98d5f1de162d1777aee97e59d75d70d07c5 - s390: Remove protvirt and kvm config guards for uv code

Thu, 04 Jul 2024 13:02:46 +0200

s390: Remove protvirt and kvm config guards for uv codeRemoving the CONFIG_PROTECTED_VIRTUALIZATION_GUEST ifdefs and configoption 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 List of files: /linux/arch/s390/boot/Makefile

7f9d85998f6c5b989796470fd1ac066232c60723 - s390/alternatives: Allow early alternative patching in decompressor

Tue, 16 Jul 2024 13:50:54 +0200

s390/alternatives: Allow early alternative patching in decompressorAdd the required code to patch alternatives early in the decompressor.This is required for the upcoming lowcore relocation changes, wherealternatives for facility 193 need to get patched before lowcorealternatives.Reviewed-by: Alexander Gordeev Co-developed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik List of files: /linux/arch/s390/boot/Makefile

008dead43d1e16b9849b388a47f7e3e647dd09ec - s390/boot: add the KMSAN runtime stub

Fri, 21 Jun 2024 13:35:08 +0200

s390/boot: add the KMSAN runtime stubIt should be possible to have inline functions in the s390 header files,which call kmsan_unpoison_memory(). The problem is that these headerfiles might be included by the decompressor, which does not contain KMSANruntime, causing linker errors.Not compiling these calls if __SANITIZE_MEMORY__ is not defined - eitherby changing kmsan-checks.h or at the call sites - may cause unintendedside effects, since calling these functions from an uninstrumented codethat is linked into the kernel is valid use case.One might want to explicitly distinguish between the kernel and thedecompressor. Checking for a decompressor-specific #define is quiteheavy-handed, and will have to be done at all call sites.A more generic approach is to provide a dummy kmsan_unpoison_memory()definition. This produces some runtime overhead, but only when buildingwith CONFIG_KMSAN. The benefit is that it does not disturb the existingKMSAN build logic and call sites don't need to be changed.Link: https://lkml.kernel.org/r/20240621113706.315500-25-iii@linux.ibm.comSigned-off-by: Ilya Leoshkevich Reviewed-by: Alexander Potapenko Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Christoph Lameter Cc: David Rientjes Cc: Dmitry Vyukov Cc: Heiko Carstens Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>Cc: Joonsoo Kim Cc: Cc: Marco Elver Cc: Mark Rutland Cc: Masami Hiramatsu (Google) Cc: Pekka Enberg Cc: Roman Gushchin Cc: Steven Rostedt (Google) Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Vlastimil Babka Signed-off-by: Andrew Morton List of files: /linux/arch/s390/boot/Makefile

c5944a7ec148b4c3e004d7f9243501094571cdd7 - s390/boot: turn off KMSAN

Fri, 21 Jun 2024 13:35:06 +0200

s390/boot: turn off KMSANAll other sanitizers are disabled for boot as well. While at it, add acomment explaining why we need this.Link: https://lkml.kernel.org/r/20240621113706.315500-23-iii@linux.ibm.comSigned-off-by: Ilya Leoshkevich Reviewed-by: Alexander Gordeev Reviewed-by: Alexander Potapenko Cc: Christian Borntraeger Cc: Christoph Lameter Cc: David Rientjes Cc: Dmitry Vyukov Cc: Heiko Carstens Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>Cc: Joonsoo Kim Cc: Cc: Marco Elver Cc: Mark Rutland Cc: Masami Hiramatsu (Google) Cc: Pekka Enberg Cc: Roman Gushchin Cc: Steven Rostedt (Google) Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Vlastimil Babka Signed-off-by: Andrew Morton List of files: /linux/arch/s390/boot/Makefile

00cda11d3b2ea07295490b7d67942014f1cbc5c1 - s390: Compile kernel with -fPIC and link with -no-pie

Thu, 25 Apr 2024 16:59:31 +0200

s390: Compile kernel with -fPIC and link with -no-pieWhen the kernel is built with CONFIG_PIE_BUILD option enabled ituses dynamic symbols, for which the linker does not allow morethan 64K number of entries. This can break features like kpatch.Hence, whenever possible the kernel is built with CONFIG_PIE_BUILDoption disabled. For that support of unaligned symbols generated bylinker scripts in the compiler is necessary.However, older compilers might lack such support. In that case thebuild process resorts to CONFIG_PIE_BUILD option-enabled build.Compile object files with -fPIC option and then link the kernelbinary with -no-pie linker option.As result, the dynamic symbols are not generated and not only kpatchfeature succeeds, but also the whole CONFIG_PIE_BUILD option-enabledcode could be dropped.[ agordeev: Reworded the commit message ]Suggested-by: Ulrich Weigand Signed-off-by: Sumanth Korikkar Reviewed-by: Alexander Gordeev Signed-off-by: Alexander Gordeev List of files: /linux/arch/s390/boot/Makefile

4f00d4ef6634b31d6026b9bf6bb1a90c889e2347 - s390: adjust indentation of RELOCS command build step out

Tue, 26 Mar 2024 11:52:23 +0100

s390: adjust indentation of RELOCS command build step outCommon pattern in non-verbose build output for quiet commands is that theshorthand of a command including whitespace contains at least eightcharacters. Adjust this for the RELOCS command, which comes only with sevencharacters.Before: SORTTAB vmlinux CC arch/s390/boot/version.o RELOCS arch/s390/boot/relocs.S OBJCOPY arch/s390/boot/info.binAfter: SORTTAB vmlinux CC arch/s390/boot/version.o RELOCS arch/s390/boot/relocs.S OBJCOPY arch/s390/boot/info.binSigned-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev List of files: /linux/arch/s390/boot/Makefile

7f115ff4fc20698452ff4a1cbb9c790be10b0066 - s390/boot: workaround current 'llvm-objdump -t -j ...' behavior

Tue, 20 Feb 2024 21:44:48 +0100

s390/boot: workaround current 'llvm-objdump -t -j ...' behaviorWhen building with OBJDUMP=llvm-objdump, there are a series of warningsfrom the section comparisons that arch/s390/boot/Makefile performsbetween vmlinux and arch/s390/boot/vmlinux: llvm-objdump: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file llvm-objdump: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input fileThe warning is a little misleading, as these sections do exist in theinput files. It is really pointing out that llvm-objdump does not matchGNU objdump's behavior of respecting '-j' / '--section' in combinationwith '-t' / '--syms': $ s390x-linux-gnu-objdump -t -j .boot.data vmlinux.full vmlinux.full: file format elf64-s390 SYMBOL TABLE: 0000000001951000 l O .boot.data 0000000000003000 sclp_info_sccb 00000000019550e0 l O .boot.data 0000000000000001 sclp_info_sccb_valid 00000000019550e2 g O .boot.data 0000000000001000 early_command_line ... $ llvm-objdump -t -j .boot.data vmlinux.full vmlinux.full: file format elf64-s390 SYMBOL TABLE: 0000000000100040 l O .text 0000000000000010 dw_psw 0000000000000000 l df *ABS* 0000000000000000 main.c 00000000001001b0 l F .text 00000000000000c6 trace_event_raw_event_initcall_level 0000000000100280 l F .text 0000000000000100 perf_trace_initcall_level ...It may be possible to change llvm-objdump's behavior to match GNUobjdump's behavior but the difficulty of that task has not yet beenexplored. The combination of '$(OBJDUMP) -t -j' is not common in thekernel tree on a whole, so workaround this tool difference by greppingfor the sections in the full symbol table output in a similar manner tothe sed invocation. This results in no visible change for GNU objdumpusers while fixing the warnings for OBJDUMP=llvm-objdump, furtherenabling use of LLVM=1 for ARCH=s390 with versions of LLVM that havesupport for s390 in ld.lld and llvm-objcopy.Reported-by: Heiko Carstens Closes: https://lore.kernel.org/20240219113248.16287-C-hca@linux.ibm.com/Link: https://github.com/ClangBuiltLinux/linux/issues/859Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20240220-s390-work-around-llvm-objdump-t-j-v1-1-47bb0366a831@kernel.orgSigned-off-by: Heiko Carstens List of files: /linux/arch/s390/boot/Makefile

778666df60f0d96f215e33e27448de47a2207fb3 - s390: compile relocatable kernel without -fPIE

Mon, 19 Feb 2024 14:27:33 +0100

s390: compile relocatable kernel without -fPIEOn s390, currently kernel uses the '-fPIE' compiler flag for compilingvmlinux. This has a few problems: - It uses dynamic symbols (.dynsym), for which the linker refuses to allow more than 64k sections. This can break features which use '-ffunction-sections' and '-fdata-sections', including kpatch-build [1] and Function Granular KASLR. - It unnecessarily uses GOT relocations, adding an extra layer of indirection for many memory accesses.Instead of using '-fPIE', resolve all the relocations at link time andthen manually adjust any absolute relocations (R_390_64) during boot.This is done by first telling the linker to preserve all relocationsduring the vmlinux link. (Note this is harmless: they are laterstripped in the vmlinux.bin link.)Then use the 'relocs' tool to find all absolute relocations (R_390_64)which apply to allocatable sections. The offsets of those relocationsare saved in a special section which is then used to adjust therelocations during boot.(Note: For some reason, Clang occasionally creates a GOT reference, evenwithout '-fPIE'. So Clang-compiled kernels have a GOT, which needs tobe adjusted.)On my mostly-defconfig kernel, this reduces kernel text size by ~1.3%.[1] https://github.com/dynup/kpatch/issues/1284[2] https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622872.html[3] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/625986.htmlCompiler consideration:Gcc recently implemented an optimization [2] for loading symbols withoutexplicit alignment, aligning with the IBM Z ELF ABI. This ABI mandatessymbols to reside on a 2-byte boundary, enabling the use of the larlinstruction. However, kernel linker scripts may still generate unalignedsymbols. To address this, a new -munaligned-symbols option has beenintroduced [3] in recent gcc versions. This option has to be used withfuture gcc versions.Older Clang lacks support for handling unaligned symbols generatedby kernel linker scripts when the kernel is built without -fPIE. However,future versions of Clang will include support for the -munaligned-symbolsoption. When the support is unavailable, compile the kernel with -fPIEto maintain the existing behavior.In addition to it:move vmlinux.relocs to safe relocationWhen the kernel is built with CONFIG_KERNEL_UNCOMPRESSED, the entireuncompressed vmlinux.bin is positioned in the bzImage decompressorimage at the default kernel LMA of 0x100000, enabling it to be executedin-place. However, the size of .vmlinux.relocs could be large enough tocause an overlap with the uncompressed kernel at the address 0x100000.To address this issue, .vmlinux.relocs is positioned after the.rodata.compressed in the bzImage. Nevertheless, in this configuration,vmlinux.relocs will overlap with the .bss section of vmlinux.bin. Toovercome that, move vmlinux.relocs to a safe location before clearing.bss and handling relocs.Compile warning fix from Sumanth Korikkar:When kernel is built with CONFIG_LD_ORPHAN_WARN and -fno-PIE, there areseveral warnings:ld: warning: orphan section `.rela.iplt' from`arch/s390/kernel/head64.o' being placed in section `.rela.dyn'ld: warning: orphan section `.rela.head.text' from`arch/s390/kernel/head64.o' being placed in section `.rela.dyn'ld: warning: orphan section `.rela.init.text' from`arch/s390/kernel/head64.o' being placed in section `.rela.dyn'ld: warning: orphan section `.rela.rodata.cst8' from`arch/s390/kernel/head64.o' being placed in section `.rela.dyn'Orphan sections are sections that exist in an object file but don't havea corresponding output section in the final executable. ld raises awarning when it identifies such sections.Eliminate the warning by placing all .rela orphan sections in .rela.dynand raise an error when size of .rela.dyn is greater than zero. i.e.Dont just neglect orphan sections.This is similar to adjustment performed in x86, where kernel is builtwith -fno-PIE.commit 5354e84598f2 ("x86/build: Add asserts for unwanted sections")[sumanthk@linux.ibm.com: rebased Josh Poimboeuf patches and move vmlinux.relocs to safe location][hca@linux.ibm.com: merged compile warning fix from Sumanth]Tested-by: Sumanth Korikkar Acked-by: Vasily Gorbik Signed-off-by: Josh Poimboeuf Signed-off-by: Sumanth Korikkar Link: https://lore.kernel.org/r/20240219132734.22881-4-sumanthk@linux.ibm.comLink: https://lore.kernel.org/r/20240219132734.22881-5-sumanthk@linux.ibm.comSigned-off-by: Heiko Carstens List of files: /linux/arch/s390/boot/Makefile

9ea30fd166e9b869546059f714beab78cb150b11 - s390/boot: add 'alloc' to info.bin .vmlinux.info section flags

Fri, 16 Feb 2024 20:55:53 +0100

s390/boot: add 'alloc' to info.bin .vmlinux.info section flagsWhen attempting to boot a kernel compiled with OBJCOPY=llvm-objcopy,there is a crash right at boot: Out of memory allocating 6d7800 bytes 8 aligned in range 0:20000000 Reserved memory ranges: 0000000000000000 a394c3c30d90cdaf DECOMPRESSOR Usable online memory ranges (info source: sclp read info [3]): 0000000000000000 0000000020000000 Usable online memory total: 20000000 Reserved: a394c3c30d90cdaf Free: 0 Call Trace: (sp:0000000000033e90 [<0000000000012fbc>] physmem_alloc_top_down+0x5c/0x104) sp:0000000000033f00 [<0000000000011d56>] startup_kernel+0x3a6/0x77c sp:0000000000033f60 [<00000000000100f4>] startup_normal+0xd4/0xd4GNU objcopy does not have any issues. Looking at differences between theobject files in each build reveals info.bin does not get properlypopulated with llvm-objcopy, which results in an empty .vmlinux.infosection. $ file {gnu,llvm}-objcopy/arch/s390/boot/info.bin gnu-objcopy/arch/s390/boot/info.bin: data llvm-objcopy/arch/s390/boot/info.bin: empty $ llvm-readelf --section-headers {gnu,llvm}-objcopy/arch/s390/boot/vmlinux | rg 'File:|\.vmlinux\.info|\.decompressor\.syms' File: gnu-objcopy/arch/s390/boot/vmlinux [12] .vmlinux.info PROGBITS 0000000000034000 035000 000078 00 WA 0 0 1 [13] .decompressor.syms PROGBITS 0000000000034078 035078 000b00 00 WA 0 0 1 File: llvm-objcopy/arch/s390/boot/vmlinux [12] .vmlinux.info PROGBITS 0000000000034000 035000 000000 00 WA 0 0 1 [13] .decompressor.syms PROGBITS 0000000000034000 035000 000b00 00 WA 0 0 1Ulrich points out that llvm-objcopy only copies sections marked as allocwith a binary output target, whereas the .vmlinux.info section is onlymarked as load. Add 'alloc' in addition to 'load', so that both objcopyimplementations work properly: $ file {gnu,llvm}-objcopy/arch/s390/boot/info.bin gnu-objcopy/arch/s390/boot/info.bin: data llvm-objcopy/arch/s390/boot/info.bin: data $ llvm-readelf --section-headers {gnu,llvm}-objcopy/arch/s390/boot/vmlinux | rg 'File:|\.vmlinux\.info|\.decompressor\.syms' File: gnu-objcopy/arch/s390/boot/vmlinux [12] .vmlinux.info PROGBITS 0000000000034000 035000 000078 00 WA 0 0 1 [13] .decompressor.syms PROGBITS 0000000000034078 035078 000b00 00 WA 0 0 1 File: llvm-objcopy/arch/s390/boot/vmlinux [12] .vmlinux.info PROGBITS 0000000000034000 035000 000078 00 WA 0 0 1 [13] .decompressor.syms PROGBITS 0000000000034078 035078 000b00 00 WA 0 0 1Closes: https://github.com/ClangBuiltLinux/linux/issues/1996Link: https://github.com/llvm/llvm-project/commit/3c02cb7492fc78fb678264cebf57ff88e478e14fSuggested-by: Ulrich Weigand Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20240216-s390-fix-boot-with-llvm-objcopy-v1-1-0ac623daf42b@kernel.orgSigned-off-by: Heiko Carstens List of files: /linux/arch/s390/boot/Makefile