Changes in Makefile

3f70ebe638581e73c8df6b3fa7eed9b45d90b083 - s390: Enable Rust support

Mon, 01 Jun 2026 19:46:25 +0200

s390: Enable Rust supportEnable building Rust code on s390 by wiring the architecture into thekernel Rust infrastructure.Add s390 to the Rust arch support documentation, provide the s390 Rusttarget and required compiler flags, and set the bindgen target forarch/s390. Adjust the Rust target generation and minimum rustc versiongating so the s390 setup is handled explicitly.The Rust toolchain uses the "s390x" triple naming for the 64 bit target.Rust support is currently incompatible with CONFIG_EXPOLINE, whichrelies on compiler support for the -mindirect-branch= and-mfunction_return= options. Therefore, select HAVE_RUST only whenEXPOLINE is disabled.Acked-by: Miguel Ojeda Acked-by: Gary Guo Acked-by: Heiko Carstens Signed-off-by: Jan Polensky Signed-off-by: Alexander Gordeev List of files: /linux/arch/s390/Makefile

f21f7b5162e9dbde6d3d5ce727d4ca2552d76ce9 - Merge tag 'timers-vdso-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Tue, 14 Apr 2026 19:53:44 +0200

Merge tag 'timers-vdso-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipPull vdso updates from Thomas Gleixner: - Make the handling of compat functions consistent and more robust - Rework the underlying data store so that it is dynamically allocated, which allows the conversion of the last holdout SPARC64 to the generic VDSO implementation - Rework the SPARC64 VDSO to utilize the generic implementation - Mop up the left overs of the non-generic VDSO support in the core code - Expand the VDSO selftest and make them more robust - Allow time namespaces to be enabled independently of the generic VDSO support, which was not possible before due to SPARC64 not using it - Various cleanups and improvements in the related code* tag 'timers-vdso-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (51 commits) timens: Use task_lock guard in timens_get*() timens: Use mutex guard in proc_timens_set_offset() timens: Simplify some calls to put_time_ns() timens: Add a __free() wrapper for put_time_ns() timens: Remove dependency on the vDSO vdso/timens: Move functions to new file selftests: vDSO: vdso_test_correctness: Add a test for time() selftests: vDSO: vdso_test_correctness: Use facilities from parse_vdso.c selftests: vDSO: vdso_test_correctness: Handle different tv_usec types selftests: vDSO: vdso_test_correctness: Drop SYS_getcpu fallbacks selftests: vDSO: vdso_test_gettimeofday: Remove nolibc checks Revert "selftests: vDSO: parse_vdso: Use UAPI headers instead of libc headers" random: vDSO: Remove ifdeffery random: vDSO: Trim vDSO includes vdso/datapage: Trim down unnecessary includes vdso/datapage: Remove inclusion of gettimeofday.h vdso/helpers: Explicitly include vdso/processor.h vdso/gettimeofday: Add explicit includes random: vDSO: Add explicit includes MIPS: vdso: Explicitly include asm/vdso/vdso.h ... List of files: /linux/arch/s390/Makefile

ec4c28276c140a9338700041112f64f8d7ccc3e9 - kbuild: Consolidate C dialect options

Mon, 23 Feb 2026 20:10:28 +0100

kbuild: Consolidate C dialect optionsIntroduce CC_FLAGS_DIALECT to make it easier to update the variousplaces in the tree that rely on the GNU C standard and Microsoftextensions flags atomically. All remaining uses of '-std=gnu11' and'-fms-extensions' are in the tools directory (which has its own buildsystem) and other standalone Makefiles. This will allow the kernel touse a narrower option to enable the Microsoft anonymous tagged structureextension in a simpler manner. Place the CC_FLAGS_DIALECT block afterthe configuration include (so that a future change can move theselection of the flag to Kconfig) but before thearch/$(SRCARCH)/Makefile include (so that CC_FLAGS_DIALECT is availablefor use in those Makefiles).Signed-off-by: Nathan Chancellor Reviewed-by: Nicolas Schier Acked-by: Ard Biesheuvel Acked-by: Helge Deller # pariscLink: https://patch.msgid.link/20260223-fms-anonymous-structs-v1-1-8ee406d3c36c@kernel.orgSigned-off-by: Nicolas Schier List of files: /linux/arch/s390/Makefile

08b5dcb6139975f3fd754c27f4943720c3c43ae2 - s390: Add -m64 to KBUILD_CPPFLAGS

Mon, 02 Mar 2026 08:58:39 +0100

s390: Add -m64 to KBUILD_CPPFLAGSSome non-code files, like linkescripts, are preprocessed with the Cpreprocessor and make use of regular kernel headers.As -m64 is not passed to those preprocessor invocations this leadsto an inconsistency between __BITS_PER_LONG and the C type 'long'.An upcoming consistency check will be tripped by this.Make sure -m64 is also defined for those preprocessing steps.As KBUILD_CPPFLAGS is inherited by both KBUILD_AFLAGS and KBUILD_CFLAGS,drop -m64 from these variables.Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20260302-vdso-compat-checkflags-v2-3-78e55baa58ba@linutronix.de List of files: /linux/arch/s390/Makefile

2547f79b0b0cd969ae6f736890af4ebd9368cda5 - Merge tag 's390-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

Wed, 03 Dec 2025 01:37:00 +0100

Merge tag 's390-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxPull s390 updates from Heiko Carstens: - Provide a new interface for dynamic configuration and deconfiguration of hotplug memory, allowing with and without memmap_on_memory support. This makes the way memory hotplug is handled on s390 much more similar to other architectures - Remove compat support. There shouldn't be any compat user space around anymore, therefore get rid of a lot of code which also doesn't need to be tested anymore - Add stackprotector support. GCC 16 will get new compiler options, which allow to generate code required for kernel stackprotector support - Merge pai_crypto and pai_ext PMU drivers into a new driver. This removes a lot of duplicated code. The new driver is also extendable and allows to support new PMUs - Add driver override support for AP queues - Rework and extend zcrypt and AP trace events to allow for tracing of crypto requests - Support block sizes larger than 65535 bytes for CCW tape devices - Since the rework of the virtual kernel address space the module area and the kernel image are within the same 4GB area. This eliminates the need of weak per cpu variables. Get rid of ARCH_MODULE_NEEDS_WEAK_PER_CPU - Various other small improvements and fixes* tag 's390-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (92 commits) watchdog: diag288_wdt: Remove KMSG_COMPONENT macro s390/entry: Use lay instead of aghik s390/vdso: Get rid of -m64 flag handling s390/vdso: Rename vdso64 to vdso s390: Rename head64.S to head.S s390/vdso: Use common STABS_DEBUG and DWARF_DEBUG macros s390: Add stackprotector support s390/modules: Simplify module_finalize() slightly s390: Remove KMSG_COMPONENT macro s390/percpu: Get rid of ARCH_MODULE_NEEDS_WEAK_PER_CPU s390/ap: Restrict driver_override versus apmask and aqmask use s390/ap: Rename mutex ap_perms_mutex to ap_attr_mutex s390/ap: Support driver_override for AP queue devices s390/ap: Use all-bits-one apmask/aqmask for vfio in_use() checks s390/debug: Update description of resize operation s390/syscalls: Switch to generic system call table generation s390/syscalls: Remove system call table pointer from thread_struct s390/uapi: Remove 31 bit support from uapi header files s390: Remove compat support tools: Remove s390 compat support ... List of files: /linux/arch/s390/Makefile

c0087d807ae86cc82cc356e366d2dccf0e3bb225 - s390/vdso: Rename vdso64 to vdso

Mon, 24 Nov 2025 16:04:29 +0100

s390/vdso: Rename vdso64 to vdsoSince compat is gone there is only a 64 bit vdso left.Remove the superfluous "64" suffix everywhere.Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens List of files: /linux/arch/s390/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/Makefile

4ac286c4a8d904c8818a6f019da8117ec31b2c27 - s390/syscalls: Switch to generic system call table generation

Mon, 10 Nov 2025 19:54:40 +0100

s390/syscalls: Switch to generic system call table generationThe s390 syscall.tbl format differs slightly from most others, andtherefore requires an s390 specific system call table generationscript.With compat support gone use the opportunity to switch to genericsystem call table generation. The abi for all 64 bit system calls isnow common, since there is no need to specify if system call entrypoints are only for 64 bit anymore.Furthermore create the system call table in C instead of assemblercode in order to get type checking for all system call functionscontained within the table.Reviewed-by: Arnd Bergmann Signed-off-by: Heiko Carstens List of files: /linux/arch/s390/Makefile

8e0b986c59c67e08ada646249f834655a9e6da16 - s390: Remove compat support

Mon, 10 Nov 2025 19:54:37 +0100

s390: Remove compat supportThere shouldn't be any 31 bit code around anymore that matters.Remove the compat layer support required to run 31 bit code.Reason for removal is code simplification and reduced test effort.Note that this comes without any deprecation warnings added to configoptions, or kernel messages, since most likely those would be ignoredanyway.If it turns out there is still a reason to keep the compat layer thiscan be reverted at any time in the future.Reviewed-by: Arnd Bergmann Signed-off-by: Heiko Carstens List of files: /linux/arch/s390/Makefile

5ff8ad3909524ad55297a434f87c238224825bf4 - kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS

Fri, 31 Oct 2025 02:26:28 +0100

kbuild: Add '-fms-extensions' to areas with dedicated CFLAGSThis is a follow up to commit c4781dc3d1cf ("Kbuild: enable-fms-extensions") but in a separate change due to being substantiallydifferent from the initial submission.There are many places within the kernel that use their own CFLAGSinstead of the main KBUILD_CFLAGS, meaning code written with the mainkernel's use of '-fms-extensions' in mind that may be tangentiallyincluded in these areas will result in "error: declaration does notdeclare anything" messages from the compiler.Add '-fms-extensions' to all these areas to ensure consistency, alongwith -Wno-microsoft-anon-tag to silence clang's warning about use of theextension that the kernel cares about using. parisc does not build withclang so it does not need this warning flag. LoongArch does not need iteither because -W flags from KBUILD_FLAGS are pulled into cflags-vdso.Reported-by: Christian Brauner Closes: https://lore.kernel.org/20251030-meerjungfrau-getrocknet-7b46eacc215d@brauner/Reviewed-by: Christian Brauner Acked-by: Ard Biesheuvel Signed-off-by: Nathan Chancellor List of files: /linux/arch/s390/Makefile

fa7a0a53eeb7e16402f82c3d5a9ef4bf5efe9357 - s390: Add -Wno-pointer-sign to KBUILD_CFLAGS_DECOMPRESSOR

Fri, 26 Sep 2025 15:39:10 +0200

s390: Add -Wno-pointer-sign to KBUILD_CFLAGS_DECOMPRESSORIf the decompressor is compiled with clang this can lead to the followingwarning:In file included from arch/s390/boot/startup.c:4:...In file included from ./include/linux/pgtable.h:6:./arch/s390/include/asm/pgtable.h:2065:48: warning: passing 'unsigned long *' to parameter of type 'long *' converts between pointers to integer types with different sign [-Wpointer-sign] 2065 | value = __atomic64_or_barrier(PGSTE_PCL_BIT, ptr);Add -Wno-pointer-sign to the decompressor compile flags, like it is alsodone for the kernel. This is similar to what was done for x86 to addressthe same problem [1].[1] commit dca5203e3fe2 ("x86/boot: Add -Wno-pointer-sign to KBUILD_CFLAGS")Cc: stable@vger.kernel.orgReported-by: Gerd Bayer Signed-off-by: Heiko Carstens Reviewed-by: Alexander Gordeev Signed-off-by: Alexander Gordeev List of files: /linux/arch/s390/Makefile

c51ea9888e88fc20df656dab01263f17529c7374 - s390: Allow to compile with z17 optimizations

Mon, 26 Aug 2024 22:13:47 +0200

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

f4d2ef48250ad057e4f00087967b5ff366da9f39 - Merge tag 'kbuild-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Sun, 06 Apr 2025 00:46:50 +0200

Merge tag 'kbuild-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuildPull Kbuild updates from Masahiro Yamada: - Improve performance in gendwarfksyms - Remove deprecated EXTRA_*FLAGS and KBUILD_ENABLE_EXTRA_GCC_CHECKS - Support CONFIG_HEADERS_INSTALL for ARCH=um - Use more relative paths to sources files for better reproducibility - Support the loong64 Debian architecture - Add Kbuild bash completion - Introduce intermediate vmlinux.unstripped for architectures that need static relocations to be stripped from the final vmlinux - Fix versioning in Debian packages for -rc releases - Treat missing MODULE_DESCRIPTION() as an error - Convert Nios2 Makefiles to use the generic rule for built-in DTB - Add debuginfo support to the RPM package* tag 'kbuild-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (40 commits) kbuild: rpm-pkg: build a debuginfo RPM kconfig: merge_config: use an empty file as initfile nios2: migrate to the generic rule for built-in DTB rust: kbuild: skip `--remap-path-prefix` for `rustdoc` kbuild: pacman-pkg: hardcode module installation path kbuild: deb-pkg: don't set KBUILD_BUILD_VERSION unconditionally modpost: require a MODULE_DESCRIPTION() kbuild: make all file references relative to source root x86: drop unnecessary prefix map configuration kbuild: deb-pkg: add comment about future removal of KDEB_COMPRESS kbuild: Add a help message for "headers" kbuild: deb-pkg: remove "version" variable in mkdebian kbuild: deb-pkg: fix versioning for -rc releases Documentation/kbuild: Fix indentation in modules.rst example x86: Get rid of Makefile.postlink kbuild: Create intermediate vmlinux build with relocations preserved kbuild: Introduce Kconfig symbol for linking vmlinux with relocations kbuild: link-vmlinux.sh: Make output file name configurable kbuild: do not generate .tmp_vmlinux*.map when CONFIG_VMLINUX_MAP=y Revert "kheaders: Ignore silly-rename files" ... List of files: /linux/arch/s390/Makefile

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

Tue, 25 Mar 2025 19:02:45 +0100

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

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

Tue, 11 Mar 2025 12:06:19 +0100

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

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

Thu, 23 Jan 2025 03:54:27 +0100

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

27939d6cde904bcea19d0cdb64a79eedf5abc7ce - s390/Kconfig: Select VMAP_STACK unconditionally

Mon, 02 Dec 2024 12:56:38 +0100

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

435dc41efdd3f0a98bd3e128799b0e04697a2d2c - s390: use a larger stack for KMSAN

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

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

ba05b39d54eef78043b5c8ee90545cb06a98ae6f - s390/expoline: Make modules use kernel expolines

Wed, 17 Jan 2024 11:50:49 +0100

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