summaryrefslogtreecommitdiffstats
path: root/Makefile
AgeCommit message (Collapse)Author
2019-10-29Linux 4.19.81v4.19.81Greg Kroah-Hartman
2019-10-17Linux 4.19.80v4.19.80Greg Kroah-Hartman
2019-10-11Linux 4.19.79v4.19.79Greg Kroah-Hartman
2019-10-07Linux 4.19.78v4.19.78Greg Kroah-Hartman
2019-10-05Linux 4.19.77v4.19.77Greg Kroah-Hartman
2019-10-01Linux 4.19.76v4.19.76Greg Kroah-Hartman
2019-09-21Linux 4.19.75v4.19.75Greg Kroah-Hartman
2019-09-19Linux 4.19.74v4.19.74Greg Kroah-Hartman
2019-09-16Linux 4.19.73v4.19.73Greg Kroah-Hartman
2019-09-10Linux 4.19.72v4.19.72Greg Kroah-Hartman
2019-09-06Linux 4.19.71v4.19.71Greg Kroah-Hartman
2019-09-06Linux 4.19.70v4.19.70Greg Kroah-Hartman
2019-08-29Linux 4.19.69v4.19.69Greg Kroah-Hartman
2019-08-25Linux 4.19.68v4.19.68Greg Kroah-Hartman
2019-08-16Linux 4.19.67v4.19.67Greg Kroah-Hartman
2019-08-09Linux 4.19.66v4.19.66Greg Kroah-Hartman
2019-08-06Linux 4.19.65v4.19.65Greg Kroah-Hartman
2019-08-06kbuild: initialize CLANG_FLAGS correctly in the top MakefileMasahiro Yamada
commit 5241ab4cf42d3a93b933b55d3d53f43049081fa1 upstream. CLANG_FLAGS is initialized by the following line: CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%)) ..., which is run only when CROSS_COMPILE is set. Some build targets (bindeb-pkg etc.) recurse to the top Makefile. When you build the kernel with Clang but without CROSS_COMPILE, the same compiler flags such as -no-integrated-as are accumulated into CLANG_FLAGS. If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg', Kbuild will recompile everything needlessly due to the build command change. Fix this by correctly initializing CLANG_FLAGS. Fixes: 238bcbc4e07f ("kbuild: consolidate Clang compiler flags") Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-04Linux 4.19.64v4.19.64Greg Kroah-Hartman
2019-07-31Linux 4.19.63v4.19.63Greg Kroah-Hartman
2019-07-31kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGSNathan Chancellor
[ Upstream commit 589834b3a0097a4908f4112eac0ca2feb486fa32 ] In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is a GCC only option so clang rightfully complains: warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option] https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option However, by default, this is merely a warning so the build happily goes on with a slew of these warnings in the process. Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang") worked around this behavior in cc-option by adding -Werror so that unknown flags cause an error. However, this all happens silently and when an unknown flag is added to the build unconditionally like -Wno-psabi, cc-option will always fail because there is always an unknown flag in the list of flags. This manifested as link time failures in the arm64 libstub because -fno-stack-protector didn't get added to KBUILD_CFLAGS. To avoid these weird cryptic failures in the future, make clang behave like gcc and immediately error when it encounters an unknown flag by adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added unconditionally for clang because it is supported by at least 3.0.0, according to godbolt [1] and 4.0.0, according to its documentation [2], which is far earlier than we typically support. [1]: https://godbolt.org/z/7F7rm3 [2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option Link: https://github.com/ClangBuiltLinux/linux/issues/511 Link: https://github.com/ClangBuiltLinux/linux/issues/517 Suggested-by: Peter Smith <peter.smith@linaro.org> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-28Linux 4.19.62v4.19.62Greg Kroah-Hartman
2019-07-26Linux 4.19.61v4.19.61Greg Kroah-Hartman
2019-07-21Linux 4.19.60v4.19.60Greg Kroah-Hartman
2019-07-14Linux 4.19.59v4.19.59Greg Kroah-Hartman
2019-07-10Linux 4.19.58v4.19.58Greg Kroah-Hartman
2019-07-03Linux 4.19.57v4.19.57Greg Kroah-Hartman
2019-06-25Linux 4.19.56v4.19.56Greg Kroah-Hartman
2019-06-25gcc-9: silence 'address-of-packed-member' warningLinus Torvalds
commit 6f303d60534c46aa1a239f29c321f95c83dda748 upstream. We already did this for clang, but now gcc has that warning too. Yes, yes, the address may be unaligned. And that's kind of the point. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-22Linux 4.19.55v4.19.55Greg Kroah-Hartman
2019-06-22Linux 4.19.54v4.19.54Greg Kroah-Hartman
2019-06-19Linux 4.19.53v4.19.53Greg Kroah-Hartman
2019-06-17Linux 4.19.52v4.19.52Greg Kroah-Hartman
2019-06-15Linux 4.19.51v4.19.51Greg Kroah-Hartman
2019-06-11Linux 4.19.50v4.19.50Greg Kroah-Hartman
2019-06-09Linux 4.19.49v4.19.49Greg Kroah-Hartman
2019-06-04Linux 4.19.48v4.19.48Greg Kroah-Hartman
2019-06-04jump_label: move 'asm goto' support test to KconfigMasahiro Yamada
commit e9666d10a5677a494260d60d1fa0b73cc7646eb3 upstream. Currently, CONFIG_JUMP_LABEL just means "I _want_ to use jump label". The jump label is controlled by HAVE_JUMP_LABEL, which is defined like this: #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL) # define HAVE_JUMP_LABEL #endif We can improve this by testing 'asm goto' support in Kconfig, then make JUMP_LABEL depend on CC_HAS_ASM_GOTO. Ugly #ifdef HAVE_JUMP_LABEL will go away, and CONFIG_JUMP_LABEL will match to the real kernel capability. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Tested-by: Sedat Dilek <sedat.dilek@gmail.com> [nc: Fix trivial conflicts in 4.19 arch/xtensa/kernel/jump_label.c doesn't exist yet Ensured CC_HAVE_ASM_GOTO and HAVE_JUMP_LABEL were sufficiently eliminated] Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-31Linux 4.19.47v4.19.47Greg Kroah-Hartman
2019-05-25Linux 4.19.46v4.19.46Greg Kroah-Hartman
2019-05-22Linux 4.19.45v4.19.45Greg Kroah-Hartman
2019-05-22kbuild: turn auto.conf.cmd into a mandatory include fileMasahiro Yamada
commit d2f8ae0e4c5c754f1b2a7b8388d19a1a977e698a upstream. syncconfig is responsible for keeping auto.conf up-to-date, so if it fails for any reason, the build must be terminated immediately. However, since commit 9390dff66a52 ("kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing"), Kbuild continues running even after syncconfig fails. You can confirm this by intentionally making syncconfig error out: # diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c # index 08ba146..307b9de 100644 # --- a/scripts/kconfig/confdata.c # +++ b/scripts/kconfig/confdata.c # @@ -1023,6 +1023,9 @@ int conf_write_autoconf(int overwrite) # FILE *out, *tristate, *out_h; # int i; # # + if (overwrite) # + return 1; # + # if (!overwrite && is_present(autoconf_name)) # return 0; Then, syncconfig fails, but Make would not stop: $ make -s mrproper allyesconfig defconfig $ make scripts/kconfig/conf --syncconfig Kconfig *** Error during sync of the configuration. make[2]: *** [scripts/kconfig/Makefile;69: syncconfig] Error 1 make[1]: *** [Makefile;557: syncconfig] Error 2 make: *** [include/config/auto.conf.cmd] Deleting file 'include/config/tristate.conf' make: Failed to remake makefile 'include/config/auto.conf'. 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 [ continue running ... ] The reason is in the behavior of a pattern rule with multi-targets. %/auto.conf %/auto.conf.cmd %/tristate.conf: $(KCONFIG_CONFIG) $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig GNU Make knows this rule is responsible for making all the three files simultaneously. As far as examined, auto.conf.cmd is the target in question when this rule is invoked. It is probably because auto.conf.cmd is included below the inclusion of auto.conf. The inclusion of auto.conf is mandatory, while that of auto.conf.cmd is optional. GNU Make does not care about the failure in the process of updating optional include files. I filed this issue (https://savannah.gnu.org/bugs/?56301) in case this behavior could be improved somehow in future releases of GNU Make. Anyway, it is quite easy to fix our Makefile. Given that auto.conf is already a mandatory include file, there is no reason to stick auto.conf.cmd optional. Make it mandatory as well. Cc: linux-stable <stable@vger.kernel.org> # 5.0+ Fixes: 9390dff66a52 ("kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> [commented out diff above to keep patch happy - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-16Linux 4.19.44v4.19.44Greg Kroah-Hartman
2019-05-14Linux 4.19.43v4.19.43Greg Kroah-Hartman
2019-05-10Linux 4.19.42v4.19.42Greg Kroah-Hartman
2019-05-08Linux 4.19.41v4.19.41Greg Kroah-Hartman
2019-05-05Linux 4.19.40v4.19.40Greg Kroah-Hartman
2019-05-04Linux 4.19.39v4.19.39Greg Kroah-Hartman
2019-05-02Linux 4.19.38v4.19.38Greg Kroah-Hartman
2019-04-27Linux 4.19.37v4.19.37Greg Kroah-Hartman