- 12 Sep, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210910122915.942645251@linuxfoundation.org Tested-by:
Fox Chen <foxhlchen@gmail.com> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 08 Sep, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210906125449.112564040@linuxfoundation.org Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
-
- 03 Sep, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210901122301.984263453@linuxfoundation.org Tested-by:
-
- 26 Aug, 2021 1 commit
-
-
Sasha Levin authored
Tested-by:
Sasha Levin <sashal@kernel.org>
-
- 18 Aug, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210816125444.082226187@linuxfoundation.org Tested-by:
-
- 15 Aug, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210813150520.090373732@linuxfoundation.org Tested-by:
-
- 12 Aug, 2021 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210810173000.928681411@linuxfoundation.org Tested-by:
Aakash Hemadri <aakashhemadri123@gmail.com> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 14ccc638 ] Since commit bcf637f5 ("kbuild: parse C= and M= before changing the working directory"), external module builds invoked by DKMS fail because M= option is not parsed. I wanted to add 'unset sub_make_done' in install.sh but similar scripts, arch/*/boot/install.sh, are duplicated, so I set sub_make_done empty in the top Makefile. Fixes: bcf637f5 ("kbuild: parse C= and M= before changing the working directory") Reported-by:
John S Gruber <johnsgruber@gmail.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Tested-by:
-
- 08 Aug, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210806081113.718626745@linuxfoundation.org Tested-by:
Aakash Hemadri <aakashhemdri123@gmail.com> Tested-by:
-
- 04 Aug, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210802134344.028226640@linuxfoundation.org Tested-by:
-
- 31 Jul, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210729135137.336097792@linuxfoundation.org Tested-by:
-
- 28 Jul, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210726153846.245305071@linuxfoundation.org Tested-by:
-
- 25 Jul, 2021 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210722155628.371356843@linuxfoundation.org Tested-by:
-
Masahiro Yamada authored
commit d952cfaf upstream. When a new CONFIG option is available, Kbuild shows a prompt to get the user input. $ make [ snip ] Core Scheduling for SMT (SCHED_CORE) [N/y/?] (NEW) This is the only interactive place in the build process. Commit 174a1dcc ("kbuild: sink stdout from cmd for silent build") suppressed Kconfig prompts as well because syncconfig is invoked by the 'cmd' macro. You cannot notice the fact that Kconfig is waiting for the user input. Use 'kecho' to show the equivalent short log without suppressing stdout from sub-make. Fixes: 174a1dcc ("kbuild: sink stdout from cmd for silent build") Reported-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
-
- 20 Jul, 2021 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210719144944.537151528@linuxfoundation.org Tested-by:
-
Masahiro Yamada authored
[ Upstream commit 74ee585b ] M= (or KBUILD_EXTMOD) generally expects a directory path without any trailing slashes, like M=a/b/c. If you add a trailing slash, like M=a/b/c/, you will get ugly build logs (two slashes in a series), but it still works fine as long as it is consistent between 'make modules' and 'make modules_install'. The following commands correctly build and install the modules. $ make M=a/b/c/ modules $ sudo make M=a/b/c/ modules_install Since commit ccae4cfa ("kbuild: refactor scripts/Makefile.modinst"), a problem happens if you add a trailing slash only for modules_install. $ make M=a/b/c modules $ sudo make M=a/b/c/ modules_install No module is installed in this case, Johannes Berg reported. [1] Trim any trailing slashes from $(KBUILD_EXTMOD). I used the 'dirname' command to remove all the trailing slashes in case someone adds more slashes like M=a/b/c/////. The Make's built-in function, $(dir ...) cannot take care of such a case. [1]: https://lore.kernel.org/lkml/10cc8522b27a051e6a9c3e158a4c4b6414fd04a0.camel@sipsolutions.net/ Fixes: ccae4cfa ("kbuild: refactor scripts/Makefile.modinst") Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
- 19 Jul, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210715182613.933608881@linuxfoundation.org Tested-by:
-
- 14 Jul, 2021 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210712060912.995381202@linuxfoundation.org Tested-by:
-
Nick Desaulniers authored
[ Upstream commit 27f2a4db ] GDB produces the following warning when debugging kernels built with CONFIG_RELR: BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn' when loading a kernel built with CONFIG_RELR into GDB. It can also prevent debugging symbols using such relocations. Peter sugguests: [That flag] means that lld will use dynamic tags and section type numbers in the OS-specific range rather than the generic range. The kernel itself doesn't care about these numbers; it determines the location of the RELR section using symbols defined by a linker script. Link: https://github.com/ClangBuiltLinux/linux/issues/1057 Suggested-by:
Peter Collingbourne <pcc@google.com> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20210522012626.2811297-1-ndesaulniers@google.com Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
- 07 Jul, 2021 1 commit
-
-
Sasha Levin authored
Tested-by:
-
- 27 Jun, 2021 1 commit
-
-
Linus Torvalds authored
-
- 20 Jun, 2021 1 commit
-
-
Linus Torvalds authored
-
- 14 Jun, 2021 1 commit
-
-
Tor Vic authored
Since LLVM commit fc018eb, the '-warn-stack-size' flag has been dropped [1], leading to the following error message when building with Clang-13 and LLD-13: ld.lld: error: -plugin-opt=-: ld.lld: Unknown command line argument '-warn-stack-size=2048'. Try: 'ld.lld --help' ld.lld: Did you mean '--asan-stack=2048'? In the same way as with commit 2398ce80 ("x86, lto: Pass -stack-alignment only on LLD < 13.0.0") , make '-warn-stack-size' conditional on LLD < 13.0.0. [1] https://reviews.llvm.org/D103928 Fixes: 24845dcb ("Makefile: LTO: have linker check -Wframe-larger-than") Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1377 Signed-off-by:Tor Vic <torvic9@mailbox.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/7631bab7-a8ab-f884-ab54-f4198976125c@mailbox.org
-
- 13 Jun, 2021 1 commit
-
-
Linus Torvalds authored
-
- 06 Jun, 2021 1 commit
-
-
Linus Torvalds authored
-
- 30 May, 2021 1 commit
-
-
Linus Torvalds authored
-
- 24 May, 2021 1 commit
-
-
Nick Desaulniers authored
-Wframe-larger-than= requires stack frame information, which the frontend cannot provide. This diagnostic is emitted late during compilation once stack frame size is available. When building with LTO, the frontend simply lowers C to LLVM IR and does not have stack frame information, so it cannot emit this diagnostic. When the linker drives LTO, it restarts optimizations and lowers LLVM IR to object code. At that point, it has stack frame information but doesn't know to check for a specific max stack frame size. I consider this a bug in LLVM that we need to fix. There are some details we're working out related to LTO such as which value to use when there are multiple different values specified per TU, or how to propagate these to compiler synthesized routines properly, if at all. Until it's fixed, ensure we don't miss these. At that point we can wrap this in a compiler version guard or revert this based on the minimum support version of Clang. The error message is not generated during link: LTO vmlinux.o ld.lld: warning: stack size limit exceeded (8224) in foobarbaz Cc: Sami Tolvanen <samitolvanen@google.com> Reported-by:
Candle Sun <candlesea@gmail.com> Suggested-by:
Fangrui Song <maskray@google.com> Signed-off-by:
-
- 23 May, 2021 1 commit
-
-
Linus Torvalds authored
-
- 16 May, 2021 1 commit
-
-
Linus Torvalds authored
-
- 09 May, 2021 1 commit
-
-
Linus Torvalds authored
-
- 05 May, 2021 3 commits
-
-
Masahiro Yamada authored
The supported targets for external modules are listed in the help target a few lines below. Let's not have duplicated information in two places. Signed-off-by: -
Masahiro Yamada authored
'make tags' and friends create tag files in the top directory, but people may manually create tag files in sub-directories. Signed-off-by: -
Masahiro Yamada authored
This reverts the old commit [1], which seems questionable to me. It claimed 'make distclean' could not remove editor backup files, but I believe KBUILD_OUTPUT or O= was set. When O= is given, Kbuild should always work against $(objtree). If O= is not given, $(objtree) and $(srctree) are the same, therefore $(srctree) is cleaned up. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=dd47df980c02eb33833b2690b033c34fba2fa80d Signed-off-by:
-
- 03 May, 2021 1 commit
-
-
Masahiro Yamada authored
Commit 37744fee ("sh: remove sh5 support") removed the SUPERH64 support entirely. Remove the left-over code from the top Makefile. Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
- 01 May, 2021 2 commits
-
-
Nathan Chancellor authored
Currently, -Wunused-but-set-variable is only supported by GCC so it is disabled unconditionally in a GCC only block (it is enabled with W=1). clang currently has its implementation for this warning in review so preemptively move this statement out of the GCC only block and wrap it with cc-disable-warning so that both compilers function the same. Cc: stable@vger.kernel.org Link: https://reviews.llvm.org/D100581 Signed-off-by:
-
Masahiro Yamada authored
We maintain .gitignore and Makefiles so build artifacts are properly ignored by Git, and cleaned up by 'make clean'. However, the code is always changing; generated files are often moved to another directory, or removed when they become unnecessary. Such garbage files tend to be left over in the source tree because people usually git-pull without cleaning the tree. This is not only the noise for 'git status', but also a build issue in some cases. One solution is to remove a stale file like commit 223c24a7 ("kbuild: Automatically remove stale <linux/version.h> file") did. Such workaround should be removed after a while, but we forget about that if we scatter the workaround code in random places. So, this commit adds a new script to collect cleanings of stale files. As a start point, move the code in arch/arm/boot/compressed/Makefile into this script. Signed-off-by:
-
- 25 Apr, 2021 1 commit
-
-
Linus Torvalds authored
-
- 24 Apr, 2021 3 commits
-
-
Nathan Chancellor authored
Normally, invocations of $(HOSTCC) include $(KBUILD_HOSTLDFLAGS), which in turn includes $(HOSTLDFLAGS), which allows users to pass in their own flags when linking. However, the 'has_libelf' test does not, meaning that if a user requests a specific linker via HOSTLDFLAGS=-fuse-ld=..., it is not respected and the build might error. For example, if a user building with clang wants to use all of the LLVM tools without any GNU tools, they might remove all of the GNU tools from their system or PATH then build with $ make HOSTLDFLAGS=-fuse-ld=lld LLVM=1 LLVM_IAS=1 which says use all of the LLVM tools, the integrated assembler, and ld.lld for linking host executables. Without this change, the build will error because $(HOSTCC) uses its default linker, rather than the one requested via -fuse-ld=..., which is GNU ld in clang's case in a default configuration. error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel make[1]: *** [Makefile:1260: prepare-objtool] Error 1 Add $(KBUILD_HOSTLDFLAGS) to the 'has_libelf' test so that the linker choice is respected. Link: https://github.com/ClangBuiltLinux/linux/issues/479 Signed-off-by:
-
Masahiro Yamada authored
scripts/Makefile.modsign is a subset of scripts/Makefile.modinst, and duplicates the code. Let's merge them. By the way, you do not need to run 'make modules_sign' explicitly because modules are signed as a part of 'make modules_install' when CONFIG_MODULE_SIG_ALL=y. If CONFIG_MODULE_SIG_ALL=n, mod_sign_cmd is set to 'true', so 'make modules_sign' is not functional. In my understanding, the reason of still keeping this is to handle corner cases like commit 64178cb6 ("builddeb: fix stripped module signatures if CONFIG_DEBUG_INFO and CONFIG_MODULE_SIG_ALL are set"). Signed-off-by:
-
Masahiro Yamada authored
Both mod_strip_cmd and mod_compress_cmd are only used in scripts/Makefile.modinst, hence there is no good reason to define them in the top Makefile. Move the relevant code to scripts/Makefile.modinst. Also, show separate log messages for each of install, strip, sign, and compress. Signed-off-by:
-
