kernel/linux.git/arch/um/Makefile, branch v6.6.134

um: let 'make clean' properly clean underlying SUBARCH as well

2025-06-04T12:42:25+00:00

[ Upstream commit ab09da75700e9d25c7dfbc7f7934920beb5e39b9 ] Building the kernel with O= is affected by stale in-tree build artifacts. So, if the source tree is not clean, Kbuild displays the following: $ make ARCH=um O=build defconfig make[1]: Entering directory '/.../linux/build' *** *** The source tree is not clean, please run 'make ARCH=um mrproper' *** in /.../linux *** make[2]: *** [/.../linux/Makefile:673: outputmakefile] Error 1 make[1]: *** [/.../linux/Makefile:248: __sub-make] Error 2 make[1]: Leaving directory '/.../linux/build' make: *** [Makefile:248: __sub-make] Error 2 Usually, running 'make mrproper' is sufficient for cleaning the source tree for out-of-tree builds. However, building UML generates build artifacts not only in arch/um/, but also in the SUBARCH directory (i.e., arch/x86/). If in-tree stale files remain under arch/x86/, Kbuild will reuse them instead of creating new ones under the specified build directory. This commit makes 'make ARCH=um clean' recurse into the SUBARCH directory. Reported-by: Shuah Khan Closes: https://lore.kernel.org/lkml/20250502172459.14175-1-skhan@linuxfoundation.org/ Signed-off-by: Masahiro Yamada Acked-by: Johannes Berg Reviewed-by: David Gow Reviewed-by: Shuah Khan Signed-off-by: Sasha Levin

um: Fix adding '-no-pie' for clang

2024-02-23T08:25:03+00:00

commit 846cfbeed09b45d985079a9173cf390cc053715b upstream. The kernel builds with -fno-PIE, so commit 883354afbc10 ("um: link vmlinux with -no-pie") added the compiler linker flag '-no-pie' via cc-option because '-no-pie' was only supported in GCC 6.1.0 and newer. While this works for GCC, this does not work for clang because cc-option uses '-c', which stops the pipeline right before linking, so '-no-pie' is unconsumed and clang warns, causing cc-option to fail just as it would if the option was entirely unsupported: $ clang -Werror -no-pie -c -o /dev/null -x c /dev/null clang-16: error: argument unused during compilation: '-no-pie' [-Werror,-Wunused-command-line-argument] A recent version of clang exposes this because it generates a relocation under '-mcmodel=large' that is not supported in PIE mode: /usr/sbin/ld: init/main.o: relocation R_X86_64_32 against symbol `saved_command_line' can not be used when making a PIE object; recompile with -fPIE /usr/sbin/ld: failed to set dynamic section sizes: bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) Remove the cc-option check altogether. It is wasteful to invoke the compiler to check for '-no-pie' because only one supported compiler version does not support it, GCC 5.x (as it is supported with the minimum version of clang and GCC 6.1.0+). Use a combination of the gcc-min-version macro and CONFIG_CC_IS_CLANG to unconditionally add '-no-pie' with CONFIG_LD_SCRIPT_DYN=y, so that it is enabled with all compilers that support this. Furthermore, using gcc-min-version can help turn this back into LINK-$(CONFIG_LD_SCRIPT_DYN) += -no-pie when the minimum version of GCC is bumped past 6.1.0. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/1982 Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

um: use obj-y to descend into arch/um/*/

2023-08-26T20:41:34+00:00

The single build rule does not work with the core-y syntax. [1] Use the standard obj-y syntax. [1]: https://lore.kernel.org/linux-kbuild/d57ba55f-20a3-b836-783d-b49c8a161b6e@kernel.org/T/#m7bc402e1e038f00ebcf2e92ed7fcb8a52fc1ea44 Signed-off-by: Masahiro Yamada Tested-by: Jiri Slaby Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Signed-off-by: Richard Weinberger

um: Hard-code the result of 'uname -s'

2023-08-26T20:40:37+00:00

We rely on 'uname -s' returning 'Linux' because there are os-Linux/ directories, but no other os-*/. Supporting a non-Linux host is unlikely to happen. Let's hard-code 'Linux'. Signed-off-by: Masahiro Yamada Signed-off-by: Richard Weinberger

um: Use HOST_DIR for mrproper

2023-06-14T19:27:38+00:00

When HEADER_ARCH was introduced, the MRPROPER_FILES (then MRPROPER_DIRS) list wasn't adjusted, leaving SUBARCH as part of the path argument. This resulted in the "mrproper" target not cleaning up arch/x86/... when SUBARCH was specified. Since HOST_DIR is arch/$(HEADER_ARCH), use it instead to get the correct path. Cc: Richard Weinberger Cc: Anton Ivanov Cc: Johannes Berg Cc: Azeem Shaikh Cc: linux-um@lists.infradead.org Fixes: 7bbe7204e937 ("um: merge Makefile-{i386,x86_64}") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20230606222442.never.807-kees@kernel.org

um: Support LTO

2023-02-13T09:14:31+00:00

Only a handful of changes are necessary to get it to work. Signed-off-by: Peter Foley Signed-off-by: Richard Weinberger

um: Use CFLAGS_vmlinux

2023-02-13T09:14:20+00:00

link-vmlinux.sh doesn't use LDFLAGS_vmlinux when linking the kernel for UML. Move the LDFLAGS_EXESTACK options into CFLAGS_vmlinux so they're actually respected. e.g. /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: warning: .tmp_vmlinux.kallsyms3.o: missing .note.GNU-stack section implies executable stack /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: warning: vmlinux has a LOAD segment with RWX permissions Reviewed-by: David Gow Signed-off-by: Peter Foley Signed-off-by: Richard Weinberger

rust: arch/um: Use 'pie' relocation mode under UML

2023-02-10T20:27:32+00:00

UML expects a position independent executable for some reason, so tell rustc to generate pie objects. Otherwise we get a bunch of relocations we can't deal with in libcore. Signed-off-by: David Gow Signed-off-by: Richard Weinberger

arch: um: Mark the stack non-executable to fix a binutils warning

2022-09-21T07:11:42+00:00

Since binutils 2.39, ld will print a warning if any stack section is executable, which is the default for stack sections on files without a .note.GNU-stack section. This was fixed for x86 in commit ffcf9c5700e4 ("x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments"), but remained broken for UML, resulting in several warnings: /usr/bin/ld: warning: arch/x86/um/vdso/vdso.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: vmlinux has a LOAD segment with RWX permissions Link both the VDSO and vmlinux with -z noexecstack, fixing the warnings about .note.GNU-stack sections. In addition, pass --no-warn-rwx-segments to dodge the remaining warnings about LOAD segments with RWX permissions in the kallsyms objects. (Note that this flag is apparently not available on lld, so hide it behind a test for BFD, which is what the x86 patch does.) Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136 Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Signed-off-by: David Gow Reviewed-by: Lukas Straub Tested-by: Lukas Straub Acked-by: Randy Dunlap # build-tested Signed-off-by: Richard Weinberger

Revert "um: clang: Strip out -mno-global-merge from USER_CFLAGS"

2022-04-01T15:05:28+00:00

This reverts commit 6580c5c18fb3df2b11c5e0452372f815deeff895. This patch is buggy, as noted in the patch linked below. The root cause has been solved by removing '-mno-global-merge' for the entire kernel. Link: https://lore.kernel.org/r/20220322173547.677760-1-nathan@kernel.org/ Signed-off-by: Nathan Chancellor Reviewed-by: David Gow Reviewed-by: Kees Cook Signed-off-by: Masahiro Yamada