Changes in Makefile

c51ea988 - s390: Allow to compile with z17 optimizations

Mon, 26 Aug 2024 20:13:47 +0000

s390: Allow to compile with z17 optimizationsAdd config and compile options which allow to compile with z17optimizations if the compiler supports it. Add themiscellaneous-instruction-extension 4 facility to the list of facilitiesfor z17.Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/Makefile

991a2017 - s390: Fix linker error when -no-pie option is unavailable

Tue, 25 Mar 2025 18:02:45 +0000

s390: Fix linker error when -no-pie option is unavailableThe kernel build may fail if the linker does not support -no-pie option,as it always included in LDFLAGS_vmlinux.Error log:s390-linux-ld: unable to disambiguate: -no-pie (did you mean --no-pie ?)Although the GNU linker defaults to -no-pie, the ability to explicitlyspecify this option was introduced in binutils 2.36.Hence, fix it by adding -no-pie to LDFLAGS_vmlinux only when it isavailable.Cc: stable@vger.kernel.orgFixes: 00cda11d3b2e ("s390: Compile kernel with -fPIC and link with -no-pie")Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503220342.T3fElO9L-lkp@intel.com/Suggested-by: Jens Remus Reviewed-by: Jens Remus Signed-off-by: Sumanth Korikkar Signed-off-by: Vasily Gorbik List of files: /linux-6.15/arch/s390/Makefile

9b400d17 - kbuild: Introduce Kconfig symbol for linking vmlinux with relocations

Tue, 11 Mar 2025 11:06:19 +0000

kbuild: Introduce Kconfig symbol for linking vmlinux with relocationsSome architectures build vmlinux with static relocations preserved, butstrip them again from the final vmlinux image. Arch specific toolsconsume these static relocations in order to construct relocation tablesfor KASLR.The fact that vmlinux is created, consumed and subsequently updated goesagainst the typical, declarative paradigm used by Make, which is basedon rules and dependencies. So as a first step towards cleaning this up,introduce a Kconfig symbol to declare that the arch wants to consume thestatic relocations emitted into vmlinux. This will be wired up furtherin subsequent patches.Signed-off-by: Ard Biesheuvel Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/s390/Makefile

3b8b80e9 - s390: Add '-std=gnu11' to decompressor and purgatory CFLAGS

Thu, 23 Jan 2025 02:54:27 +0000

s390: Add '-std=gnu11' to decompressor and purgatory CFLAGSGCC changed the default C standard dialect from gnu17 to gnu23,which should not have impacted the kernel because it explicitly requeststhe gnu11 standard in the main Makefile. However, there are certainplaces in the s390 code that use their own CFLAGS without a '-std='value, which break with this dialect change because of the kernel's owndefinitions of bool, false, and true conflicting with the C23 reservedkeywords. include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant 11 | false = 0, | ^~~~~ include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards include/linux/types.h:35:33: error: 'bool' cannot be defined via 'typedef' 35 | typedef _Bool bool; | ^~~~ include/linux/types.h:35:33: note: 'bool' is a keyword with '-std=c23' onwardsAdd '-std=gnu11' to the decompressor and purgatory CFLAGS to eliminatethese errors and make the C standard version of these areas match therest of the kernel.Cc: stable@vger.kernel.orgSigned-off-by: Nathan Chancellor Tested-by: Heiko Carstens Link: https://lore.kernel.org/r/20250122-s390-fix-std-for-gcc-15-v1-1-8b00cadee083@kernel.orgSigned-off-by: Alexander Gordeev List of files: /linux-6.15/arch/s390/Makefile

27939d6c - s390/Kconfig: Select VMAP_STACK unconditionally

Mon, 02 Dec 2024 11:56:38 +0000

s390/Kconfig: Select VMAP_STACK unconditionallyThere is no point in supporting !VMAP_STACK kernel builds. VMAP_STACK hasproven to work since many years. Also, since KASAN_VMALLOC is supported,kernels built with !VMAP_STACK are completely untested.Therefore select VMAP_STACK unconditionally and remove all config optionsand code required for !VMAP_STACK builds.Acked-by: Christian Borntraeger Reviewed-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev List of files: /linux-6.15/arch/s390/Makefile

435dc41e - s390: use a larger stack for KMSAN

Fri, 21 Jun 2024 11:35:07 +0000

s390: use a larger stack for KMSANAdjust the stack size for the KMSAN-enabled kernel like it was done forthe KASAN-enabled one in commit 7fef92ccadd7 ("s390/kasan: double thestack size"). Both tools have similar requirements.Link: https://lkml.kernel.org/r/20240621113706.315500-24-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-6.15/arch/s390/Makefile

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

Thu, 25 Apr 2024 14:59:31 +0000

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-6.15/arch/s390/Makefile

ba05b39d - s390/expoline: Make modules use kernel expolines

Wed, 17 Jan 2024 10:50:49 +0000

s390/expoline: Make modules use kernel expolinesCurrently, kernel modules contain their own set of expoline thunks. Inthe case of EXPOLINE_EXTERN, this involves postlinking of precompiledexpoline.o. expoline.o is also necessary for out-of-source tree modulebuilds.Now that the kernel modules area is less than 4 GB away fromkernel expoline thunks, make modules use kernel expolines. Also makeEXPOLINE_EXTERN the default if the compiler supports it. This simplifiesbuild and aligns with the approach adopted by other architectures.Signed-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev List of files: /linux-6.15/arch/s390/Makefile

5f58bde7 - s390/mm: provide simple ARCH_HAS_DEBUG_VIRTUAL support

Thu, 07 Mar 2024 12:28:27 +0000

s390/mm: provide simple ARCH_HAS_DEBUG_VIRTUAL supportProvide a very simple ARCH_HAS_DEBUG_VIRTUAL implementation.For now errors are only reported for the following cases:- Trying to translate a vmalloc or module address to a physical address- Translating a supposed to be ZONE_DMA virtual address into a physical address, and the resulting physical address is larger than two GiBReviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/Makefile

778666df - s390: compile relocatable kernel without -fPIE

Mon, 19 Feb 2024 13:27:33 +0000

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-6.15/arch/s390/Makefile

55cce52f - s390: link vmlinux with '-z notext'

Thu, 08 Feb 2024 00:15:03 +0000

s390: link vmlinux with '-z notext'ld.bfd defaults to '-z notext' (although it is customizable with the'--enable-textrel-check' configure option) but ld.lld defaults to '-ztext', which causes issues with building the kernel due to the presenceof dynamic relocations in sections that are not writable. ld.lld: error: relocation R_390_64 cannot be used against local symbol; recompile with -fPICAdd '-z notext' to avoid these errors, as this is expected, whichmatches other architectures.Signed-off-by: Nathan Chancellor Tested-by: Justin Stitt Reviewed-by: Fangrui Song Link: https://lore.kernel.org/r/20240207-s390-lld-and-orphan-warn-v1-11-8a665b3346ab@kernel.orgSigned-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/Makefile

56769ba4 - kbuild: unify vdso_install rules

Sat, 14 Oct 2023 10:54:35 +0000

kbuild: unify vdso_install rulesCurrently, there is no standard implementation for vdso_install,leading to various issues: 1. Code duplication Many architectures duplicate similar code just for copying files to the install destination. Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication. 2. Unintended updates of in-tree build artifacts The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux"). 3. Broken code in some architectures Makefile code is often copied from one architecture to another without proper adaptation. 'make vdso_install' for parisc does not work. 'make vdso_install' for s390 installs vdso64, but not vdso32.To address these problems, this commit introduces a generic vdso_installrule.Architectures that support vdso_install need to define vdso-install-yin arch/*/Makefile. vdso-install-y lists the files to install.For example, arch/x86/Makefile looks like this: vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbgThese files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,if exists, stripped away.vdso-install-y can optionally take the second field after the colonseparator. This is needed because some architectures install a vdsofile as a different base name.The following is a snippet from arch/arm64/Makefile. vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.soThis will rename vdso.so.dbg to vdso32.so during installation. If sucharchitectures change their implementation so that the base names match,this workaround will go away.Signed-off-by: Masahiro Yamada Acked-by: Sven Schnelle # s390Reviewed-by: Nicolas Schier Reviewed-by: Guo Ren Acked-by: Helge Deller # pariscAcked-by: Catalin Marinas Acked-by: Russell King (Oracle) List of files: /linux-6.15/arch/s390/Makefile

305b9f4f - s390: use obj-y to descend into drivers/s390/

Fri, 21 Jul 2023 17:13:58 +0000

s390: use obj-y to descend into drivers/s390/The single build rule does not work with the drivers-y syntax. [1]Use the standard obj-y syntax. It moves the objects from drivers/s390/to slightly lower address, but fixes the reported issue.[1]: https://lore.kernel.org/linux-kbuild/d57ba55f-20a3-b836-783d-b49c8a161b6e@kernel.org/T/#m27f781ab60acadfed8a9e9642f30d5414a5e2df3Signed-off-by: Masahiro Yamada Tested-by: Jiri Slaby Link: https://lore.kernel.org/r/20230721171358.3612099-1-masahiroy@kernel.orgSigned-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/Makefile

938f0c35 - s390/decompressor: fix misaligned symbol build error

Thu, 22 Jun 2023 12:55:08 +0000

s390/decompressor: fix misaligned symbol build errorNathan Chancellor reported a kernel build error on Fedora 39:$ clang --version | head -1clang version 16.0.5 (Fedora 16.0.5-1.fc39)$ s390x-linux-gnu-ld --version | head -1GNU ld version 2.40-1.fc39$ make -skj"$(nproc)" ARCH=s390 CC=clang CROSS_COMPILE=s390x-linux-gnu- olddefconfig alls390x-linux-gnu-ld: arch/s390/boot/startup.o(.text+0x5b4): misaligned symbol `_decompressor_end' (0x35b0f) for relocation R_390_PC32DBLmake[3]: *** [.../arch/s390/boot/Makefile:78: arch/s390/boot/vmlinux] Error 1It turned out that the problem with misaligned symbols on s390 was fixedwith commit 80ddf5ce1c92 ("s390: always build relocatable kernel") for thekernel image, but did not take into account that the decompressor uses itsown set of CFLAGS, which come without -fPIE.Add the -fPIE flag also to the decompresser CFLAGS to fix this.Reported-by: Nathan Chancellor Tested-by: Nathan Chancellor Reported-by: CKI Suggested-by: Ulrich Weigand Link: https://github.com/ClangBuiltLinux/linux/issues/1747Link: https://lore.kernel.org/32935.123062114500601371@us-mta-9.us.mimecast.lan/Link: https://lore.kernel.org/r/20230622125508.1068457-1-hca@linux.ibm.comCc: Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev List of files: /linux-6.15/arch/s390/Makefile

7bb2107e - s390: reintroduce expoline dependence to scripts

Thu, 16 Mar 2023 11:28:09 +0000

s390: reintroduce expoline dependence to scriptsExpolines depend on scripts/basic/fixdep. And build of expolines can nowrace with the fixdep build: make[1]: *** Deleting file 'arch/s390/lib/expoline/expoline.o' /bin/sh: line 1: scripts/basic/fixdep: Permission denied make[1]: *** [../scripts/Makefile.build:385: arch/s390/lib/expoline/expoline.o] Error 126 make: *** [../arch/s390/Makefile:166: expoline_prepare] Error 2The dependence was removed in the below Fixes: commit. So reintroducethe dependence on scripts.Fixes: a0b0987a7811 ("s390/nospec: remove unneeded header includes")Cc: Joe Lawrence Cc: stable@vger.kernel.orgCc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: linux-s390@vger.kernel.orgSigned-off-by: Jiri Slaby (SUSE) Link: https://lore.kernel.org/r/20230316112809.7903-1-jirislaby@kernel.orgSigned-off-by: Vasily Gorbik List of files: /linux-6.15/arch/s390/Makefile

80ddf5ce - s390: always build relocatable kernel

Sun, 30 Oct 2022 18:22:02 +0000

s390: always build relocatable kernelNathan Chancellor reported several link errors on s390 withCONFIG_RELOCATABLE disabled, after binutils commit 906f69cf65da ("IBMzSystems: Issue error for *DBL relocs on misaligned symbols"). The binutilscommit reveals potential miscompiles that might have happened alreadybefore with linker script defined symbols at odd addresses.A similar bug was recently fixed in the kernel with commit c9305b6c1f52("s390: fix nospec table alignments").See https://github.com/ClangBuiltLinux/linux/issues/1747 for an analysisfrom Ulich Weigand.Therefore always build a relocatable kernel to avoid this problem. There ishardly any use-case for non-relocatable kernels, so this shouldn't becontroversial.Link: https://github.com/ClangBuiltLinux/linux/issues/1747Signed-off-by: Heiko Carstens Reported-by: Nathan Chancellor Tested-by: Nathan Chancellor Link: https://lore.kernel.org/r/20221030182202.2062705-1-hca@linux.ibm.comSigned-off-by: Alexander Gordeev List of files: /linux-6.15/arch/s390/Makefile

ce697cce - kbuild: remove head-y syntax

Sat, 24 Sep 2022 18:19:15 +0000

kbuild: remove head-y syntaxKbuild puts the objects listed in head-y at the head of vmlinux.Conventionally, we do this for head*.S, which contains the kernel entrypoint.A counter approach is to control the section order by the linker script.Actually, the code marked as __HEAD goes into the ".head.text" section,which is placed before the normal ".text" section.I do not know if both of them are needed. From the build systemperspective, head-y is not mandatory. If you can achieve the proper codeplacement by the linker script only, it would be cleaner.I collected the current head-y objects into head-object-list.txt. It isa whitelist. My hope is it will be reduced in the long run.Signed-off-by: Masahiro Yamada Tested-by: Nick Desaulniers Reviewed-by: Nicolas Schier List of files: /linux-6.15/arch/s390/Makefile

a0b0987a - s390/nospec: remove unneeded header includes

Mon, 27 Jun 2022 12:50:56 +0000

s390/nospec: remove unneeded header includesCommit 4efd417f298b ("s390: raise minimum supported machine generationto z10") removed the usage of alternatives and lowcore in expolinesmacros. Remove unneeded header includes as well.With that, expoline.S doesn't require asm-offsets.h andexpoline_prepare target dependency could be removed.Tested-by: Joe Lawrence Link: https://lore.kernel.org/r/patch-2.thread-d13b6c.git-d13b6c96fb5f.your-ad-here.call-01656331067-ext-4899@work.hoursSigned-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev List of files: /linux-6.15/arch/s390/Makefile

c4e78957 - s390/nospec: build expoline.o for modules_prepare target

Mon, 27 Jun 2022 12:50:53 +0000

s390/nospec: build expoline.o for modules_prepare targetWhen CONFIG_EXPOLINE_EXTERN is used expoline thunks are generatedfrom arch/s390/lib/expoline.S and postlinked into every module.This is also true for external modules. Add expoline.o build tothe modules_prepare target.Fixes: 1d2ad084800e ("s390/nospec: add an option to use thunk-extern")Reported-by: Joe Lawrence Tested-by: Sumanth Korikkar Acked-by: Sumanth Korikkar Tested-by: C. Erastus Toe Tested-by: Joe Lawrence Link: https://lore.kernel.org/r/patch-1.thread-d13b6c.git-a2387a74dc49.your-ad-here.call-01656331067-ext-4899@work.hoursSigned-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev List of files: /linux-6.15/arch/s390/Makefile

f0be87c4 - gcc-12: disable '-Warray-bounds' universally for now

Thu, 09 Jun 2022 17:11:12 +0000

gcc-12: disable '-Warray-bounds' universally for nowIn commit 8b202ee21839 ("s390: disable -Warray-bounds") the s390 peopledisabled the '-Warray-bounds' warning for gcc-12, because the new logicin gcc would cause warnings for their use of the S390_lowcore macro,which accesses absolute pointers.It turns out gcc-12 has many other issues in this area, so this takesthat s390 warning disable logic, and turns it into a kernel build configentry instead.Part of the intent is that we can make this all much more targeted, anduse this conflig flag to disable it in only particular configurationsthat cause problems, with the s390 case as an example: select GCC12_NO_ARRAY_BOUNDSand we could do that for other configuration cases that cause issues.Or we could possibly use the CONFIG_CC_NO_ARRAY_BOUNDS thing in a moretargeted way, and disable the warning only for particular uses: againthe s390 case as an example: KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_CC_NO_ARRAY_BOUNDS),-Wno-array-bounds)but this ends up just doing it globally in the top-level Makefile, sincethe current issues are spread fairly widely all over: KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-boundsWe'll try to limit this later, since the gcc-12 problems are rare enoughthat *much* of the kernel can be built with it without disabling thiswarning.Cc: Kees Cook Cc: Nathan Chancellor Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/s390/Makefile