|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6 |
|
| #
ab09da75 |
| 07-May-2025 |
Masahiro Yamada <[email protected]> |
um: let 'make clean' properly clean underlying SUBARCH as well
Building the kernel with O= is affected by stale in-tree build artifacts.
So, if the source tree is not clean, Kbuild displays the fol
um: let 'make clean' properly clean underlying SUBARCH as well
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 <[email protected]> Closes: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Johannes Berg <[email protected]> Reviewed-by: David Gow <[email protected]> Reviewed-by: Shuah Khan <[email protected]>
show more ...
|
|
Revision tags: v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6 |
|
| #
2f278b59 |
| 03-Nov-2024 |
Benjamin Berg <[email protected]> |
um: always include kconfig.h and compiler-version.h
Since commit a95b37e20db9 ("kbuild: get <linux/compiler_types.h> out of <linux/kconfig.h>") we can safely include these files in userspace code. D
um: always include kconfig.h and compiler-version.h
Since commit a95b37e20db9 ("kbuild: get <linux/compiler_types.h> out of <linux/kconfig.h>") we can safely include these files in userspace code. Doing so simplifies matters as options do not need to be exported via asm-offsets.h anymore.
Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
show more ...
|
|
Revision tags: v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1 |
|
| #
32e8eaf2 |
| 19-Sep-2024 |
Benjamin Berg <[email protected]> |
um: use execveat to create userspace MMs
Using clone will not undo features that have been enabled by libc. An example of this already happening is rseq, which could cause the kernel to read/write m
um: use execveat to create userspace MMs
Using clone will not undo features that have been enabled by libc. An example of this already happening is rseq, which could cause the kernel to read/write memory of the userspace process. In the future the standard library might also use mseal by default to protect itself, which would also thwart our attempts at unmapping everything.
Solve all this by taking a step back and doing an execve into a tiny static binary that sets up the minimal environment required for the stub without using any standard library. That way we have a clean execution environment that is fully under the control of UML.
Note that this changes things a bit as the FDs are not anymore shared with the kernel. Instead, we explicitly share the FDs for the physical memory and all existing iomem regions. Doing this is fine, as iomem regions cannot be added at runtime.
Signed-off-by: Benjamin Berg <[email protected]> Link: https://patch.msgid.link/[email protected] [use pipe() instead of pipe2(), remove unneeded close() calls] Signed-off-by: Johannes Berg <[email protected]>
show more ...
|
|
Revision tags: v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1 |
|
| #
19ee6923 |
| 23-Mar-2024 |
Yueh-Shun Li <[email protected]> |
um: Makefile: use bash from the environment
Set Makefile SHELL to bash instead of /bin/bash for better portability.
Some systems do not install binaries to /bin, and therefore do not provide /bin/b
um: Makefile: use bash from the environment
Set Makefile SHELL to bash instead of /bin/bash for better portability.
Some systems do not install binaries to /bin, and therefore do not provide /bin/bash. This includes Linux distros which intentionally avoid implementing the Filesystem Hierarchy Standard (FHS), such as NixOS and Guix System.
The recipies inside arch/um/Makefile don't require top-level Bash to build, and setting "SHELL" to "bash" makes Make pick the Bash executable from the environment, hence this patch.
Changes since last roll: - Rebase onto a more recent commit on the master branch. - Remove a dangling in-text citation from the change log. - Reword the change log.
Signed-off-by: Yueh-Shun Li <[email protected]> Reviewed-by: Johannes Berg <[email protected] Signed-off-by: Richard Weinberger <[email protected]>
show more ...
|
|
Revision tags: v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2 |
|
| #
846cfbee |
| 23-Jan-2024 |
Nathan Chancellor <[email protected]> |
um: Fix adding '-no-pie' for clang
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'
um: Fix adding '-no-pie' for clang
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: [email protected] Closes: https://github.com/ClangBuiltLinux/linux/issues/1982 Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3 |
|
| #
8f85f93b |
| 21-Jul-2023 |
Masahiro Yamada <[email protected]> |
um: use obj-y to descend into arch/um/*/
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
um: use obj-y to descend into arch/um/*/
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/[email protected]/T/#m7bc402e1e038f00ebcf2e92ed7fcb8a52fc1ea44
Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Jiri Slaby <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
show more ...
|
| #
d32df108 |
| 21-Jul-2023 |
Masahiro Yamada <[email protected]> |
um: Hard-code the result of 'uname -s'
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
um: Hard-code the result of 'uname -s'
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 <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
show more ...
|
|
Revision tags: v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6 |
|
| #
a5a319ec |
| 06-Jun-2023 |
Kees Cook <[email protected]> |
um: Use HOST_DIR for mrproper
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 "mrpro
um: Use HOST_DIR for mrproper
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 <[email protected]> Cc: Anton Ivanov <[email protected]> Cc: Johannes Berg <[email protected]> Cc: Azeem Shaikh <[email protected]> Cc: [email protected] Fixes: 7bbe7204e937 ("um: merge Makefile-{i386,x86_64}") Cc: [email protected] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4 |
|
| #
83e913f5 |
| 13-Jan-2023 |
Peter Foley <[email protected]> |
um: Support LTO
Only a handful of changes are necessary to get it to work.
Signed-off-by: Peter Foley <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
|
| #
6aa56115 |
| 13-Jan-2023 |
Peter Foley <[email protected]> |
um: Use CFLAGS_vmlinux
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/li
um: Use CFLAGS_vmlinux
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 <[email protected]> Signed-off-by: Peter Foley <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
show more ...
|
|
Revision tags: v6.2-rc3, v6.2-rc2, v6.2-rc1 |
|
| #
905a7707 |
| 17-Dec-2022 |
David Gow <[email protected]> |
rust: arch/um: Use 'pie' relocation mode under UML
UML expects a position independent executable for some reason, so tell rustc to generate pie objects. Otherwise we get a bunch of relocations we ca
rust: arch/um: Use 'pie' relocation mode under UML
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 <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
show more ...
|
|
Revision tags: v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7 |
|
| #
bd71558d |
| 21-Sep-2022 |
David Gow <[email protected]> |
arch: um: Mark the stack non-executable to fix a binutils warning
Since binutils 2.39, ld will print a warning if any stack section is executable, which is the default for stack sections on files wi
arch: um: Mark the stack non-executable to fix a binutils warning
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 <[email protected]> Reviewed-by: Lukas Straub <[email protected]> Tested-by: Lukas Straub <[email protected]> Acked-by: Randy Dunlap <[email protected]> # build-tested Signed-off-by: Richard Weinberger <[email protected]>
show more ...
|
|
Revision tags: v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1 |
|
| #
1e39036d |
| 30-Mar-2022 |
Nathan Chancellor <[email protected]> |
Revert "um: clang: Strip out -mno-global-merge from USER_CFLAGS"
This reverts commit 6580c5c18fb3df2b11c5e0452372f815deeff895.
This patch is buggy, as noted in the patch linked below. The root caus
Revert "um: clang: Strip out -mno-global-merge from USER_CFLAGS"
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/[email protected]/ Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: David Gow <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v5.17, v5.17-rc8, v5.17-rc7 |
|
| #
6580c5c1 |
| 03-Mar-2022 |
David Gow <[email protected]> |
um: clang: Strip out -mno-global-merge from USER_CFLAGS
The things built with USER_CFLAGS don't seem to recognise it as a compiler option, and print a warning: clang: warning: argument unused during
um: clang: Strip out -mno-global-merge from USER_CFLAGS
The things built with USER_CFLAGS don't seem to recognise it as a compiler option, and print a warning: clang: warning: argument unused during compilation: '-mno-global-merge' [-Wunused-command-line-argument]
Fixes: 744814d2fa ("um: Allow builds with Clang") Signed-off-by: David Gow <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
show more ...
|
|
Revision tags: v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3 |
|
| #
d8285639 |
| 24-Jul-2021 |
Masahiro Yamada <[email protected]> |
kbuild: do not require sub-make for separate output tree builds
As explained in commit 3204a7fb98a3 ("kbuild: prefix $(srctree)/ to some included Makefiles"), I want to stop using --include-dir some
kbuild: do not require sub-make for separate output tree builds
As explained in commit 3204a7fb98a3 ("kbuild: prefix $(srctree)/ to some included Makefiles"), I want to stop using --include-dir some day.
I already fixed up the top Makefile, but some arch Makefiles (mips, um, x86) still include check-in Makefiles without $(srctree)/.
Fix them up so 'need-sub-make := 1' can go away for this case.
Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3 |
|
| #
386093c6 |
| 08-Mar-2021 |
Johannes Berg <[email protected]> |
um: allow not setting extra rpaths in the linux binary
There doesn't seem to be any reason for the rpath being set in the binaries, at on systems that I tested on. On the other hand, setting rpath i
um: allow not setting extra rpaths in the linux binary
There doesn't seem to be any reason for the rpath being set in the binaries, at on systems that I tested on. On the other hand, setting rpath is actually harming binaries in some cases, e.g. if using nix-based compilation environments where /lib & /lib64 are not part of the actual environment.
Add a new Kconfig option (under EXPERT, for less user confusion) that allows disabling the rpath additions.
Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
show more ...
|
|
Revision tags: v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3 |
|
| #
893ab004 |
| 26-Jun-2020 |
Masahiro Yamada <[email protected]> |
kbuild: remove cc-option test of -fno-stack-protector
Some Makefiles already pass -fno-stack-protector unconditionally. For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.
No probl
kbuild: remove cc-option test of -fno-stack-protector
Some Makefiles already pass -fno-stack-protector unconditionally. For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.
No problem report so far about hard-coding this option. So, we can assume all supported compilers know -fno-stack-protector.
GCC 4.8 and Clang support this option (https://godbolt.org/z/_HDGzN)
Get rid of cc-option from -fno-stack-protector.
Remove CONFIG_CC_HAS_STACKPROTECTOR_NONE, which is always 'y'.
Note: arch/mips/vdso/Makefile adds -fno-stack-protector twice, first unconditionally, and second conditionally. I removed the second one.
Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Kees Cook <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]>
show more ...
|
|
Revision tags: v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5 |
|
| #
0663c68c |
| 04-May-2020 |
Masahiro Yamada <[email protected]> |
kbuild: remove {CLEAN,MRPROPER,DISTCLEAN}_DIRS
Merge {CLEAN,MRPROPER,DISTCLEAN}_DIRS into {CLEAN,MRPROPER,DISTCLEAN}_FILES because the difference is just the -r option passed to the 'rm' command.
D
kbuild: remove {CLEAN,MRPROPER,DISTCLEAN}_DIRS
Merge {CLEAN,MRPROPER,DISTCLEAN}_DIRS into {CLEAN,MRPROPER,DISTCLEAN}_FILES because the difference is just the -r option passed to the 'rm' command.
Do likewise as commit 1634f2bfdb84 ("kbuild: remove clean-dirs syntax").
Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v5.7-rc4, v5.7-rc3 |
|
| #
63ec90f1 |
| 22-Apr-2020 |
Vitor Massaru Iha <[email protected]> |
um: ensure `make ARCH=um mrproper` removes arch/$(SUBARCH)/include/generated/
In this workflow:
$ make ARCH=um defconfig && make ARCH=um -j8 [snip] $ make ARCH=um mrproper [snip] $ make ARCH=um
um: ensure `make ARCH=um mrproper` removes arch/$(SUBARCH)/include/generated/
In this workflow:
$ make ARCH=um defconfig && make ARCH=um -j8 [snip] $ make ARCH=um mrproper [snip] $ make ARCH=um defconfig O=./build_um && make ARCH=um -j8 O=./build_um [snip] CC scripts/mod/empty.o In file included from ../include/linux/types.h:6, from ../include/linux/mod_devicetable.h:12, from ../scripts/mod/devicetable-offsets.c:3: ../include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory 5 | #include <asm/types.h> | ^~~~~~~~~~~~~ compilation terminated. make[2]: *** [../scripts/Makefile.build:100: scripts/mod/devicetable-offsets.s] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [/home/iha/sdb/opensource/lkmp/linux-kselftest.git/Makefile:1140: prepare0] Error 2 make[1]: Leaving directory '/home/iha/sdb/opensource/lkmp/linux-kselftest.git/build_um' make: *** [Makefile:180: sub-make] Error 2
The cause of the error was because arch/$(SUBARCH)/include/generated files weren't properly cleaned by `make ARCH=um mrproper`.
Fixes: a788b2ed81ab ("kbuild: check arch/$(SRCARCH)/include/generated before out-of-tree build") Reported-by: Theodore Ts'o <[email protected]> Suggested-by: Masahiro Yamada <[email protected]> Signed-off-by: Vitor Massaru Iha <[email protected]> Reviewed-by: Brendan Higgins <[email protected]> Tested-by: Brendan Higgins <[email protected]> Link: https://groups.google.com/forum/#!msg/kunit-dev/QmA27YEgEgI/hvS1kiz2CwAJ Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2 |
|
| #
75dd4747 |
| 06-Jul-2019 |
Masahiro Yamada <[email protected]> |
kbuild: remove src and obj from the top Makefile
Replace $(src) and $(obj) with $(srctree) and $(objtree), respectively.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Revision tags: v5.2-rc7, v5.2-rc6, v5.2-rc5, v5.2-rc4, v5.2-rc3, v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6, v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2, v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3, v5.0-rc2, v5.0-rc1, v4.20 |
|
| #
733f4ef4 |
| 20-Dec-2018 |
Masahiro Yamada <[email protected]> |
um: remove unused filechk_gen_header in Makefile
This is a leftover of commit ecba97d4aacf ("[PATCH] uml makefiles sanitized").
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Revision tags: v4.20-rc7, v4.20-rc6, v4.20-rc5 |
|
| #
65bba042 |
| 29-Nov-2018 |
Masahiro Yamada <[email protected]> |
kbuild: fix UML build error with CONFIG_GCC_PLUGINS
UML fails to build with CONFIG_GCC_PLUGINS=y.
$ make -s ARCH=um mrproper $ make -s ARCH=um allmodconfig $ make ARCH=um UPD include/generate
kbuild: fix UML build error with CONFIG_GCC_PLUGINS
UML fails to build with CONFIG_GCC_PLUGINS=y.
$ make -s ARCH=um mrproper $ make -s ARCH=um allmodconfig $ make ARCH=um UPD include/generated/uapi/linux/version.h WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAP arch/x86/include/generated/uapi/asm/poll.h WRAP arch/x86/include/generated/asm/dma-contiguous.h WRAP arch/x86/include/generated/asm/early_ioremap.h WRAP arch/x86/include/generated/asm/export.h WRAP arch/x86/include/generated/asm/mcs_spinlock.h WRAP arch/x86/include/generated/asm/mm-arch-hooks.h SYSTBL arch/x86/include/generated/asm/syscalls_32.h SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h SYSTBL arch/x86/include/generated/asm/syscalls_64.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h HOSTCC scripts/unifdef CC arch/x86/um/user-offsets.s cc1: error: cannot load plugin ./scripts/gcc-plugins/cyc_complexity_plugin.so ./scripts/gcc-plugins/cyc_complexity_plugin.so: cannot open shared object file: No such file or directory cc1: error: cannot load plugin ./scripts/gcc-plugins/structleak_plugin.so ./scripts/gcc-plugins/structleak_plugin.so: cannot open shared object file: No such file or directory cc1: error: cannot load plugin ./scripts/gcc-plugins/latent_entropy_plugin.so ./scripts/gcc-plugins/latent_entropy_plugin.so: cannot open shared object file: No such file or directory cc1: error: cannot load plugin ./scripts/gcc-plugins/randomize_layout_plugin.so ./scripts/gcc-plugins/randomize_layout_plugin.so: cannot open shared object file: No such file or directory make[1]: *** [scripts/Makefile.build;119: arch/x86/um/user-offsets.s] Error 1 make: *** [arch/um/Makefile;152: arch/x86/um/user-offsets.s] Error 2
Reorder the preparation stage (with cleanups) to make sure gcc-plugins is built before descending to arch/x86/um/.
Fixes: 6b90bd4ba40b ("GCC plugin infrastructure") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
show more ...
|
|
Revision tags: v4.20-rc4, v4.20-rc3, v4.20-rc2, v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7, v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1 |
|
| #
d503ac53 |
| 23-Aug-2018 |
Masahiro Yamada <[email protected]> |
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.
Commit 222d394d30e7 ("kbuild: enab
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.
Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add additional options to AS") renamed AFLAGS to KBUILD_AFLAGS.
Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS.
For some reason, LDFLAGS was not renamed.
Using a well-known variable like LDFLAGS may result in accidental override of the variable.
Kbuild generally uses KBUILD_ prefixed variables for the internally appended options, so here is one more conversion to sanitize the naming convention.
I did not touch Makefiles under tools/ since the tools build system is a different world.
Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Reviewed-by: Palmer Dabbelt <[email protected]>
show more ...
|
|
Revision tags: v4.18, v4.18-rc8 |
|
| #
0004438a |
| 04-Aug-2018 |
Masahiro Yamada <[email protected]> |
um: clean up archheaders recipe
Now that '%asm-generic' is added to no-dot-config-targets, 'make asm-generic' does not include the kernel configuration.
You can simply do 'make asm-generic' in the
um: clean up archheaders recipe
Now that '%asm-generic' is added to no-dot-config-targets, 'make asm-generic' does not include the kernel configuration.
You can simply do 'make asm-generic' in the recursed top Makefile without bothering syncconfig.
Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Randy Dunlap <[email protected]> Acked-by: Richard Weinberger <[email protected]>
show more ...
|
| #
13d3d01e |
| 04-Aug-2018 |
Masahiro Yamada <[email protected]> |
um: fix parallel building with O= option
Randy Dunlap reports UML occasionally fails to build with -j<N> and O=<builddir> options.
make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/
um: fix parallel building with O= option
Randy Dunlap reports UML occasionally fails to build with -j<N> and O=<builddir> options.
make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64' UPD include/generated/uapi/linux/version.h WRAP arch/x86/include/generated/asm/dma-contiguous.h WRAP arch/x86/include/generated/asm/export.h WRAP arch/x86/include/generated/asm/early_ioremap.h WRAP arch/x86/include/generated/asm/mcs_spinlock.h WRAP arch/x86/include/generated/asm/mm-arch-hooks.h WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAP arch/x86/include/generated/uapi/asm/poll.h GEN ./Makefile make[2]: *** No rule to make target 'archheaders'. Stop. arch/um/Makefile:119: recipe for target 'archheaders' failed make[1]: *** [archheaders] Error 2 make[1]: *** Waiting for unfinished jobs.... UPD include/config/kernel.release make[1]: *** wait: No child processes. Stop. Makefile:146: recipe for target 'sub-make' failed make: *** [sub-make] Error 2
The cause of the problem is the use of '$(MAKE) KBUILD_SRC=', which recurses to the top Makefile via the $(objtree)/Makefile generated by scripts/mkmakefile.
When you run "make -j<N> O=<builddir> ARCH=um", Make can execute 'archheaders' and 'outputmakefile' targets simultaneously because there is no dependency between them.
If it happens,
$(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders
... tries to run $(objtree)/Makefile that is being updated.
The correct way for the recursion is
$(Q)$(MAKE) -f $(srctree)/Makefile ARCH=$(HEADER_ARCH) archheaders
..., which does not rely on the generated Makefile.
Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Randy Dunlap <[email protected]> Acked-by: Richard Weinberger <[email protected]>
show more ...
|