summaryrefslogtreecommitdiff
path: root/scripts/Makefile.extrawarn
AgeCommit message (Collapse)Author
2024-03-31kbuild: make -Woverride-init warnings more consistentArnd Bergmann
The -Woverride-init warn about code that may be intentional or not, but the inintentional ones tend to be real bugs, so there is a bit of disagreement on whether this warning option should be enabled by default and we have multiple settings in scripts/Makefile.extrawarn as well as individual subsystems. Older versions of clang only supported -Wno-initializer-overrides with the same meaning as gcc's -Woverride-init, though all supported versions now work with both. Because of this difference, an earlier cleanup of mine accidentally turned the clang warning off for W=1 builds and only left it on for W=2, while it's still enabled for gcc with W=1. There is also one driver that only turns the warning off for newer versions of gcc but not other compilers, and some but not all the Makefiles still use a cc-disable-warning conditional that is no longer needed with supported compilers here. Address all of the above by removing the special cases for clang and always turning the warning off unconditionally where it got in the way, using the syntax that is supported by both compilers. Fixes: 2cd3271b7a31 ("kbuild: avoid duplicate warning options") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-03-11kbuild: remove GCC's default -Wpacked-bitfield-compat flagMasahiro Yamada
Commit 4a5838ad9d2d ("kbuild: Add extra gcc checks") added the -Wpacked-bitfield-compat flag, but there is no need to add it explicitly. GCC manual says: "This warning is enabled by default. Use -Wno-packed-bitfield-compat to disable this warning." The test code in the manual: struct foo { char a:4; char b:8; } __attribute__ ((packed)); ... emits "note: offset of packed bit-field ‘b’ has changed in GCC 4.4" without W=3. Let's remove it, as it is a default with GCC. Clang does not support this flag, so its removal will not affect Clang builds. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2024-03-10kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1Nathan Chancellor
Clang enables -Wenum-enum-conversion and -Wenum-compare-conditional under -Wenum-conversion. A recent change in Clang strengthened these warnings and they appear frequently in common builds, primarily due to several instances in common headers but there are quite a few drivers that have individual instances as well. include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:955:24: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional] 955 | flags |= is_new_rate ? IWL_MAC_BEACON_CCK | ^ ~~~~~~~~~~~~~~~~~~ 956 | : IWL_MAC_BEACON_CCK_V1; | ~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:1120:21: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional] 1120 | 0) > 10 ? | ^ 1121 | IWL_MAC_BEACON_FILS : | ~~~~~~~~~~~~~~~~~~~ 1122 | IWL_MAC_BEACON_FILS_V1; | ~~~~~~~~~~~~~~~~~~~~~~ Doing arithmetic between or returning two different types of enums could be a bug, so each of the instance of the warning needs to be evaluated. Unfortunately, as mentioned above, there are many instances of this warning in many different configurations, which can break the build when CONFIG_WERROR is enabled. To avoid introducing new instances of the warnings while cleaning up the disruption for the majority of users, disable these warnings for the default build while leaving them on for W=1 builds. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2002 Link: https://github.com/llvm/llvm-project/commit/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e Acked-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-01-21Makefile: Enable -Wstringop-overflow globallyGustavo A. R. Silva
It seems that we have finished addressing all the remaining issues regarding -Wstringop-overflow. So, we are now in good shape to enable this compiler option globally. Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2024-01-18Merge tag 'kbuild-v6.8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Make Kconfig parse the input .config more precisely - Support W=c and W=e options for Kconfig - Set Kconfig int/hex symbols to zero if the 'default' property is missing - Add .editorconfig - Add scripts/git.orderFile - Add a script to detect backward-incompatible changes in UAPI headers - Resolve the symlink passed to O= option properly - Use the user-supplied mtime for all files in the builtin initramfs, which provides better reproducible builds - Fix the direct execution of debian/rules for Debian package builds - Use build ID instead of the .gnu_debuglink section for the Debian dbg package * tag 'kbuild-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (53 commits) kbuild: deb-pkg: use debian/<package> for tmpdir kbuild: deb-pkg: move 'make headers' to build-arch kbuild: deb-pkg: do not search for 'scripts' directory under arch/ kbuild: deb-pkg: use build ID instead of debug link for dbg package kbuild: deb-pkg: use more debhelper commands in builddeb kbuild: deb-pkg: remove unneeded '-f $srctree/Makefile' in debian/rules kbuild: deb-pkg: allow to run debian/rules from output directory kbuild: deb-pkg: set DEB_* variables if debian/rules is directly executed kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules kbuild: deb-pkg: factor out common Make options in debian/rules kbuild: deb-pkg: hard-code Build-Depends kbuild: deb-pkg: split debian/copyright from the mkdebian script gen_init_cpio: Apply mtime supplied by user to all file types kbuild: resolve symlinks for O= properly docs: dev-tools: Add UAPI checker documentation check-uapi: Introduce check-uapi.sh scripts: Introduce a default git.orderFile kconfig: WERROR unmet symbol dependency Add .editorconfig file for basic formatting kconfig: Use KCONFIG_CONFIG instead of .config ...
2023-12-20Makefile.extrawarn: turn on missing-prototypes globallyArnd Bergmann
Over the years we went from > 1000 of warnings to under 100 earlier this year, and I sent patches to address all the ones that I saw with compile testing randcom configs on arm64, arm and x86 kernels. This is a really useful warning, as it catches real bugs when there are mismatched prototypes. In particular with kernel control flow integrity enabled, those are no longer allowed. I have done extensive testing to ensure that there are no new build errors or warnings on any configuration of x86, arm and arm64 builds. I also made sure that at least both the normal defconfig and an allmodconfig build is clean for arc, csky, loongarch, m68k, microblaze, openrisc, parisc, powerpc, riscv, s390, and xtensa, with the respective maintainers doing most of the patches. At this point, there are five architectures with a number of known regressions: alpha, nios2, mips, sh and sparc. In the previous version of this patch, I had turned off the missing prototype warnings for the 15 architectures that still had issues, but since there are only five left, I think we can leave the rest to the maintainers (Cc'd here) as well. Link: https://lkml.kernel.org/r/20231123110506.707903-7-arnd@kernel.org Link: https://lore.kernel.org/lkml/20230810141947.1236730-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> # RISC-V Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Richard Weinberger <richard@nod.at> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Tudor Ambarus <tudor.ambarus@linaro.org> Cc: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-12-03kbuild: support W=c and W=e shorthands for KconfigMasahiro Yamada
KCONFIG_WARN_UNKNOWN_SYMBOLS=1 and KCONFIG_WERROR=1 are descriptive and suitable in scripting, but typing them from the command line can be tedious. Associate them with KBUILD_EXTRA_WARN (and the W= shorthand). Support a new letter 'c' to enable extra checks in Kconfig. You can still manage compiler warnings (W=1) and Kconfig warnings (W=c) independently. Reuse the letter 'e' to turn Kconfig warnings into errors. As usual, you can combine multiple letters in KCONFIG_EXTRA_WARN. $ KCONFIG_WARN_UNKNOWN_SYMBOLS=1 KCONFIG_WERROR=1 make defconfig can be shortened to: $ KBUILD_EXTRA_WARN=ce make defconfig or, even shorter: $ make W=ce defconfig Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2023-08-20extrawarn: move -Wrestrict into W=1 warningsArnd Bergmann
There are few of these, so enable them whenever W=1 is enabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-08-20extrawarn: enable format and stringop overflow warnings in W=1Arnd Bergmann
The stringop and format warnings got disabled globally when they were newly introduced in commit bd664f6b3e376 ("disable new gcc-7.1.1 warnings for now"), 217c3e0196758 ("disable stringop truncation warnings for now") and 5a76021c2eff7 ("gcc-10: disable 'stringop-overflow' warning for now"). In all cases, the sentiment at the time was that the warnings are useful, and we actually addressed a number of real bugs based on them, but we never managed to eliminate them all because even the build bots using W=1 builds only see the -Wstringop-truncation warnings that are enabled at that level. Move these into the W=1 section to give them a larger build coverage and actually eliminate them over time. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-08-20kbuild: avoid duplicate warning optionsArnd Bergmann
Some warning options are disabled at one place and then conditionally re-enabled later in scripts/Makefile.extrawarn. For consistency, rework this file so each of those warnings only gets etiher enabled or disabled based on the W= flags but not both. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-08-20kbuild: consolidate warning flags in scripts/Makefile.extrawarnArnd Bergmann
Warning options are enabled and disabled in inconsistent ways and inconsistent locations. Start rearranging those by moving all options into Makefile.extrawarn. This should not change any behavior, but makes sure we can group them in a way that ensures that each warning that got temporarily disabled is turned back on at an appropriate W=1 level later on. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-12-11kbuild: add -Wundef to KBUILD_CPPFLAGS for W=1 buildsMasahiro Yamada
The use of an undefined macro in an #if directive is warned, but only in *.c files. No warning from other files such as *.S, *.lds.S. Since -Wundef is a preprocessor-related warning, it should be added to KBUILD_CPPFLAGS instead of KBUILD_CFLAGS. My previous attempt [1] uncovered several issues. I could not finish fixing them all. This commit adds -Wundef to KBUILD_CPPFLAGS for W=1 builds in order to block new breakages. (The kbuild test robot tests with W=1) We can fix the warnings one by one. After fixing all of them, we can make it default in the top Makefile, and remove -Wundef from KBUILD_CFLAGS. [1]: https://lore.kernel.org/all/20221012180118.331005-2-masahiroy@kernel.org/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-10-10Merge tag 'kbuild-v6.1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Remove potentially incomplete targets when Kbuid is interrupted by SIGINT etc in case GNU Make may miss to do that when stderr is piped to another program. - Rewrite the single target build so it works more correctly. - Fix rpm-pkg builds with V=1. - List top-level subdirectories in ./Kbuild. - Ignore auto-generated __kstrtab_* and __kstrtabns_* symbols in kallsyms. - Avoid two different modules in lib/zstd/ having shared code, which potentially causes building the common code as build-in and modular back-and-forth. - Unify two modpost invocations to optimize the build process. - Remove head-y syntax in favor of linker scripts for placing particular sections in the head of vmlinux. - Bump the minimal GNU Make version to 3.82. - Clean up misc Makefiles and scripts. * tag 'kbuild-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (41 commits) docs: bump minimal GNU Make version to 3.82 ia64: simplify esi object addition in Makefile Revert "kbuild: Check if linker supports the -X option" kbuild: rebuild .vmlinux.export.o when its prerequisite is updated kbuild: move modules.builtin(.modinfo) rules to Makefile.vmlinux_o zstd: Fixing mixed module-builtin objects kallsyms: ignore __kstrtab_* and __kstrtabns_* symbols kallsyms: take the input file instead of reading stdin kallsyms: drop duplicated ignore patterns from kallsyms.c kbuild: reuse mksysmap output for kallsyms mksysmap: update comment about __crc_* kbuild: remove head-y syntax kbuild: use obj-y instead extra-y for objects placed at the head kbuild: hide error checker logs for V=1 builds kbuild: re-run modpost when it is updated kbuild: unify two modpost invocations kbuild: move vmlinux.o rule to the top Makefile kbuild: move .vmlinux.objs rule to Makefile.modpost kbuild: list sub-directories in ./Kbuild Makefile.compiler: replace cc-ifversion with compiler-specific macros ...
2022-10-03Merge tag 'hardening-v6.1-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull kernel hardening updates from Kees Cook: "Most of the collected changes here are fixes across the tree for various hardening features (details noted below). The most notable new feature here is the addition of the memcpy() overflow warning (under CONFIG_FORTIFY_SOURCE), which is the next step on the path to killing the common class of "trivially detectable" buffer overflow conditions (i.e. on arrays with sizes known at compile time) that have resulted in many exploitable vulnerabilities over the years (e.g. BleedingTooth). This feature is expected to still have some undiscovered false positives. It's been in -next for a full development cycle and all the reported false positives have been fixed in their respective trees. All the known-bad code patterns we could find with Coccinelle are also either fixed in their respective trees or in flight. The commit message in commit 54d9469bc515 ("fortify: Add run-time WARN for cross-field memcpy()") for the feature has extensive details, but I'll repeat here that this is a warning _only_, and is not intended to actually block overflows (yet). The many patches fixing array sizes and struct members have been landing for several years now, and we're finally able to turn this on to find any remaining stragglers. Summary: Various fixes across several hardening areas: - loadpin: Fix verity target enforcement (Matthias Kaehlcke). - zero-call-used-regs: Add missing clobbers in paravirt (Bill Wendling). - CFI: clean up sparc function pointer type mismatches (Bart Van Assche). - Clang: Adjust compiler flag detection for various Clang changes (Sami Tolvanen, Kees Cook). - fortify: Fix warnings in arch-specific code in sh, ARM, and xen. Improvements to existing features: - testing: improve overflow KUnit test, introduce fortify KUnit test, add more coverage to LKDTM tests (Bart Van Assche, Kees Cook). - overflow: Relax overflow type checking for wider utility. New features: - string: Introduce strtomem() and strtomem_pad() to fill a gap in strncpy() replacement needs. - um: Enable FORTIFY_SOURCE support. - fortify: Enable run-time struct member memcpy() overflow warning" * tag 'hardening-v6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: (27 commits) Makefile.extrawarn: Move -Wcast-function-type-strict to W=1 hardening: Remove Clang's enable flag for -ftrivial-auto-var-init=zero sparc: Unbreak the build x86/paravirt: add extra clobbers with ZERO_CALL_USED_REGS enabled x86/paravirt: clean up typos and grammaros fortify: Convert to struct vs member helpers fortify: Explicitly check bounds are compile-time constants x86/entry: Work around Clang __bdos() bug ARM: decompressor: Include .data.rel.ro.local fortify: Adjust KUnit test for modular build sh: machvec: Use char[] for section boundaries kunit/memcpy: Avoid pathological compile-time string size lib: Improve the is_signed_type() kunit test LoadPin: Require file with verity root digests to have a header dm: verity-loadpin: Only trust verity targets with enforcement LoadPin: Fix Kconfig doc about format of file with verity digests um: Enable FORTIFY_SOURCE lkdtm: Update tests for memcpy() run-time warnings fortify: Add run-time WARN for cross-field memcpy() fortify: Use SIZE_MAX instead of (size_t)-1 ...
2022-10-01Makefile.extrawarn: Move -Wcast-function-type-strict to W=1Sami Tolvanen
We enable -Wcast-function-type globally in the kernel to warn about mismatching types in function pointer casts. Compilers currently warn only about ABI incompability with this flag, but Clang 16 will enable a stricter version of the check by default that checks for an exact type match. This will be very noisy in the kernel, so disable -Wcast-function-type-strict without W=1 until the new warnings have been addressed. Cc: stable@vger.kernel.org Link: https://reviews.llvm.org/D134831 Link: https://github.com/ClangBuiltLinux/linux/issues/1724 Suggested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220930203310.4010564-1-samitolvanen@google.com
2022-09-29Makefile.compiler: replace cc-ifversion with compiler-specific macrosNick Desaulniers
cc-ifversion is GCC specific. Replace it with compiler specific variants. Update the users of cc-ifversion to use these new macros. Link: https://github.com/ClangBuiltLinux/linux/issues/350 Link: https://lore.kernel.org/llvm/CAGG=3QWSAUakO42kubrCap8fp-gm1ERJJAYXTnP1iHk_wrH=BQ@mail.gmail.com/ Suggested-by: Bill Wendling <morbo@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-09-04Makefile.extrawarn: re-enable -Wformat for clang; take 2Nick Desaulniers
-Wformat was recently re-enabled for builds with clang, then quickly re-disabled, due to concerns stemming from the frequency of default argument promotion related warning instances. commit 258fafcd0683 ("Makefile.extrawarn: re-enable -Wformat for clang") commit 21f9c8a13bb2 ("Revert "Makefile.extrawarn: re-enable -Wformat for clang"") ISO WG14 has ratified N2562 to address default argument promotion explicitly for printf, as part of the upcoming ISO C2X standard. The behavior of clang was changed in clang-16 to not warn for the cited cases in all language modes. Add a version check, so that users of clang-16 now get the full effect of -Wformat. For older clang versions, re-enable flags under the -Wformat group that way users still get some useful checks related to format strings, without noisy default argument promotion warnings. I intentionally omitted -Wformat-y2k and -Wformat-security from being re-enabled, which are also part of -Wformat in clang-16. Link: https://github.com/ClangBuiltLinux/linux/issues/378 Link: https://github.com/llvm/llvm-project/issues/57102 Link: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2562.pdf Suggested-by: Justin Stitt <jstitt007@gmail.com> Suggested-by: Nathan Chancellor <nathan@kernel.org> Suggested-by: Youngmin Nam <youngmin.nam@samsung.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-21scripts/Makefile.extrawarn: Do not disable clang's -Wformat-zero-lengthNathan Chancellor
There are no instances of this warning in the tree across several difference architectures and configurations. This was added by commit 26ea6bb1fef0 ("kbuild, LLVMLinux: Supress warnings unless W=1-3") back in 2014, where it might have been necessary, but there are no instances of it now so stop disabling it to increase warning coverage for clang. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-08-11Revert "Makefile.extrawarn: re-enable -Wformat for clang"Linus Torvalds
This reverts commit 258fafcd0683d9ccfa524129d489948ab3ddc24c. The clang -Wformat warning is terminally broken, and the clang people can't seem to get their act together. This test program causes a warning with clang: #include <stdio.h> int main(int argc, char **argv) { printf("%hhu\n", 'a'); } resulting in t.c:5:19: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat] printf("%hhu\n", 'a'); ~~~~ ^~~ %d and apparently clang people consider that a feature, because they don't want to face the reality of how either C character constants, C arithmetic, and C varargs functions work. The rest of the world just shakes their head at that kind of incompetence, and turns off -Wformat for clang again. And no, the "you should use a pointless cast to shut this up" is not a valid answer. That warning should not exist in the first place, or at least be optinal with some "-Wformat-me-harder" kind of option. [ Admittedly, there's also very little reason to *ever* use '%hh[ud]' in C, but what little reason there is is entirely about 'I want to see only the low 8 bits of the argument'. So I would suggest nobody ever use that format in the first place, but if they do, the clang behavious is simply always wrong. Because '%hhu' takes an 'int'. It's that simple. ] Reported-by: Sudip Mukherjee (Codethink) <sudipm.mukherjee@gmail.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-03Makefile.extrawarn: re-enable -Wformat for clangJustin Stitt
There's been an ongoing mission to re-enable the -Wformat warning for Clang. A previous attempt at enabling the warning showed that there were many instances of this warning throughout the codebase. The sheer amount of these warnings really polluted builds and thus -Wno-format was added to _temporarily_ toggle them off. After many patches the warning has largely been eradicated for x86, x86_64, arm, and arm64 on a variety of configs. The time to enable the warning has never been better as it seems for the first time we are ahead of them and can now solve them as they appear rather than tackling from a backlog. As to the root cause of this large backlog of warnings, Clang seems to pickup on some more nuanced cases of format warnings caused by implicit integer conversion as well as default argument promotions from printf-like functions. Link: https://github.com/ClangBuiltLinux/linux/issues/378 Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-05-08kbuild: support W=e to make build abort in case of warningYann Droneaud
When developing new code/feature, CONFIG_WERROR is most often turned off, especially for people using make W=12 to get more warnings. In such case, turning on -Werror temporarily would require switching on CONFIG_WERROR in the configuration, building, then switching off CONFIG_WERROR. For this use case, this patch introduces a new 'e' modifier to W= as a short hand for KCFLAGS+=-Werror" so that -Werror got added to the kernel (built-in) and modules' CFLAGS. Signed-off-by: Yann Droneaud <ydroneaud@opteya.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-13Kbuild: add -Wno-shift-negative-value where -Wextra is usedArnd Bergmann
As a preparation for moving to -std=gnu11, turn off the -Wshift-negative-value option. This warning is enabled by gcc when building with -Wextra for c99 or higher, but not for c89. Since the kernel already relies on well-defined overflow behavior, the warning is not helpful and can simply be disabled in all locations that use -Wextra. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v13.0.0 (x86-64) Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-02-08Makefile.extrawarn: Move -Wunaligned-access to W=1Nathan Chancellor
-Wunaligned-access is a new warning in clang that is default enabled for arm and arm64 under certain circumstances within the clang frontend (see LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows 1284 total/70 unique instances of this warning (most of the instances are in header files), which is quite noisy. To keep a normal build green through CONFIG_WERROR, only show this warning with W=1, which will allow automated build systems to catch new instances of the warning so that the total number can be driven down to zero eventually since catching unaligned accesses at compile time would be generally useful. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a Link: https://github.com/ClangBuiltLinux/linux/issues/1569 Link: https://github.com/ClangBuiltLinux/linux/issues/1576 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-12-08Makefile.extrawarn: remove -Wnested-externs warningArnd Bergmann
The -Wnested-externs warning has become useless with gcc, since this warns every time that BUILD_BUG_ON() or similar macros are used. With clang, the warning option does nothing to start with, so just remove it entirely. Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-11-25Makefile.extrawarn: move -Wcast-align to W=3Arnd Bergmann
This warning behaves differently depending on the architecture and compiler. Using x86 gcc, we get no output at all because gcc knows the architecture can handle unaligned accesses. Using x86 clang, or gcc on an architecture that needs to manually deal with unaligned accesses, the build log is completely flooded with these warnings, as they are commonly invoked by inline functions of networking headers, e.g. include/linux/skbuff.h:1426:26: warning: cast increases required alignment of target type [-Wcast-align] The compiler is correct to point this out, as we are dealing with undefined behavior that does cause problems in practice, but there is also no good way to rewrite the code in commonly included headers to a safer method. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-08-18Makefile.extrawarn: Move sign-compare from W=2 to W=3Joe Perches
This -Wsign-compare compiler warning can be very noisy and most of the suggested conversions are unnecessary. Make the warning W=3 so it's described under the "can most likely be ignored" block. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-07-09kbuild: Move -Wtype-limits to W=2Rikard Falkeborn
-Wtype-limits is included in -Wextra which is added at W=1. It warns (among other things) that 'comparison of an unsigned variable `< 0` is always false. This causes noisy warnings, especially when used in macros, hence it is more suitable for W=2. Link: https://lore.kernel.org/lkml/CAHk-=wiKCXEWKJ9dWUimGbrVRo_N2RosESUw8E7m9AEtyZcu=w@mail.gmail.com/ Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Suggested-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-09kbuild: Enable -Wtautological-compareNathan Chancellor
Currently, we disable -Wtautological-compare, which in turn disables a bunch of more specific tautological comparison warnings that are useful for the kernel such as -Wtautological-bitwise-compare. See clang's documentation below for the other warnings that are suppressed by -Wtautological-compare. Now that all of the major/noisy warnings have been fixed, enable -Wtautological-compare so that more issues can be caught at build time by various continuous integration setups. -Wtautological-constant-out-of-range-compare is kept disabled under a normal build but visible at W=1 because there are places in the kernel where a constant or variable size can change based on the kernel configuration. These are not fixed in a clean/concise way and the ones I have audited so far appear to be harmless. It is not a subgroup but rather just one warning so we do not lose out on much coverage by default. Link: https://github.com/ClangBuiltLinux/linux/issues/488 Link: http://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html#wtautological-compare Link: https://bugs.llvm.org/show_bug.cgi?id=42666 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-03-14kbuild: Disable -Wpointer-to-enum-castNathan Chancellor
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when casting to enums. The kernel does this in certain places, such as device tree matches to set the version of the device being used, which allows the kernel to avoid using a gigantic union. https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428 https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402 https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264 To avoid a ton of false positive warnings, disable this particular part of the warning, which has been split off into a separate diagnostic so that the entire warning does not need to be turned off for clang. It will be visible under W=1 in case people want to go about fixing these easily and enabling the warning treewide. Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/887 Link: https://github.com/llvm/llvm-project/commit/2a41b31fcdfcb67ab7038fc2ffb606fd50b83a84 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-09-09kbuild: allow Clang to find unused static inline functions for W=1 buildMasahiro Yamada
GCC and Clang have different policy for -Wunused-function; GCC does not warn unused static inline functions at all whereas Clang does if they are defined in source files instead of included headers although it has been suppressed since commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused static inline functions"). We often miss to delete unused functions where 'static inline' is used in *.c files since there is no tool to detect them. Unused code remains until somebody notices. For example, commit 075ddd75680f ("regulator: core: remove unused rdev_get_supply()"). Let's remove __maybe_unused from the inline macro to allow Clang to start finding unused static inline functions. For now, we do this only for W=1 build since it is not a good idea to sprinkle warnings for the normal build (e.g. 35 warnings for arch/x86/configs/x86_64_defconfig). My initial attempt was to add -Wno-unused-function for no W= build (https://lore.kernel.org/patchwork/patch/1120594/) Nathan Chancellor pointed out that would weaken Clang's checks since we would no longer get -Wunused-function without W=1. It is true GCC would catch unused static non-inline functions, but it would weaken Clang as a standalone compiler, at least. Hence, here is a counter implementation. The current problem is, W=... only controls compiler flags, which are globally effective. There is no way to address only 'static inline' functions. This commit defines KBUILD_EXTRA_WARN[123] corresponding to W=[123]. When KBUILD_EXTRA_WARN1 is defined, __maybe_unused is omitted from the 'inline' macro. The new macro __inline_maybe_unused makes the code a bit uglier, so I hope we can remove it entirely after fixing most of the warnings. If you contribute to code clean-up, please run "make CC=clang W=1" and check -Wunused-function warnings. You will find lots of unused functions. Some of them are false-positives because the call-sites are disabled by #ifdef. I do not like to abuse the inline keyword for suppressing unused-function warnings because it is intended to be a hint for the compiler optimization. I prefer #ifdef around the definition, or __maybe_unused if #ifdef would make the code too ugly. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
2019-09-06kbuild: rename KBUILD_ENABLE_EXTRA_GCC_CHECKS to KBUILD_EXTRA_WARNMasahiro Yamada
KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning options for GCC, but now it is a historical misnomer since we use it also for Clang, DTC, and even kernel-doc. Rename it to more sensible, shorter KBUILD_EXTRA_WARN. For the backward compatibility, KBUILD_ENABLE_EXTRA_GCC_CHECKS is still supported (but not advertised in the documentation). I also fixed up 'make help', and updated the documentation. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com>
2019-09-06kbuild: refactor scripts/Makefile.extrawarnMasahiro Yamada
Instead of the warning-[123] magic, let's accumulate compiler options to KBUILD_CFLAGS directly as the top Makefile does. I think this makes it easier to understand what is going on in this file. This commit slightly changes the behavior, I think all of which are OK. [1] Currently, cc-option calls are needlessly evaluated. For example, warning-3 += $(call cc-option, -Wpacked-bitfield-compat) needs evaluating only when W=3, but it is actually evaluated for W=1, W=2 as well. With this commit, only relevant cc-option calls will be evaluated. This is a slight optimization. [2] Currently, unsupported level like W=4 is checked by: $(error W=$(KBUILD_ENABLE_EXTRA_GCC_CHECKS) is unknown) This will no longer be checked, but I do not think it is a big deal. [3] Currently, 4 Clang warnings (Winitializer-overrides, Wformat, Wsign-compare, Wformat-zero-length) are shown by any of W=1, W=2, and W=3. With this commit, they will be warned only by W=1. I think this is a more correct behavior since each warning belongs to only one group. For understanding this commit correctly: We have 3 warning groups, W=1, W=2, and W=3. You may think W=3 has a higher level than W=1, but they are actually independent. If you like, you can combine them like W=13. To enable all the warnings, you can pass W=123. It is shown by 'make help', but not noticed much. Since we support W= combination, there should not exist intersection among the three groups. If we enable Winitializer-overrides for W=1, we do not need to for W=2 or W=3. This is the reason why I think the change [3] makes sense. The documentation says -Winitializer-overrides is enabled by default. (https://clang.llvm.org/docs/DiagnosticsReference.html#winitializer-overrides) We negate it by passing -Wno-initializer-overrides for the normal build, but we do not do that for W=1. This means, W=1 effectively enables -Winitializer-overrides by the clang's default. The same for the other three. Add comments in case people are confused with the code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
2019-06-24kbuild: Remove unnecessary -Wno-unused-valueNathan Huckleberry
This flag turns off several other warnings that would be useful. Most notably -warn_unused_result is disabled. All of the following warnings are currently disabled: UnusedValue |-UnusedComparison |-warn_unused_comparison |-UnusedResult |-warn_unused_result |-UnevaluatedExpression |-PotentiallyEvaluatedExpression |-warn_side_effects_typeid |-warn_side_effects_unevaluated_context |-warn_unused_expr |-warn_unused_voidptr |-warn_unused_container_subscript_expr |-warn_unused_call With this flag removed there are ~10 warnings. Patches have been submitted for each of these warnings. Reported-by: Nick Desaulniers <ndesaulniers@google.com> Cc: clang-built-linux@googlegroups.com Link: https://github.com/ClangBuiltLinux/linux/issues/520 Signed-off-by: Nathan Huckleberry <nhuck@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-24kbuild: Enable -WuninitializedNathan Chancellor
This helps fine very dodgy behavior through both -Wuninitialized (warning that a variable is always uninitialized) and -Wsometimes-uninitialized (warning that a variable is sometimes uninitialized, like GCC's -Wmaybe-uninitialized). These warnings catch things that GCC doesn't such as: https://lore.kernel.org/lkml/86649ee4-9794-77a3-502c-f4cd10019c36@lca.pw/ We very much want to catch these so turn this warning on so that CI is aware of it. Link: https://github.com/ClangBuiltLinux/linux/issues/381 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-09kbuild: Remove -Waggregate-return from scripts/Makefile.extrawarnMathieu Malaterre
It makes little sense to pass -Waggregate-return these days since large part of the linux kernel rely on returning struct(s). For instance: ../include/linux/timekeeping.h: In function 'show_uptime': ../include/linux/ktime.h:91:34: error: function call has aggregate value [-Werror=aggregate-return] #define ktime_to_timespec64(kt) ns_to_timespec64((kt)) ^~~~~~~~~~~~~~~~~~~~~~ ../include/linux/timekeeping.h:166:8: note: in expansion of macro 'ktime_to_timespec64' *ts = ktime_to_timespec64(ktime_get_coarse_boottime()); Remove this warning from W=2 completely. Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-05-18kbuild: add all Clang-specific flags unconditionallyMasahiro Yamada
We do not support old Clang versions. Upgrade your clang version if any of these flags is unsupported. Let's add all flags inside ifdef CONFIG_CC_IS_CLANG unconditionally. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com>
2019-05-18kbuild: add some extra warning flags unconditionallyMasahiro Yamada
These flags are documented in the GCC 4.6 manual, and recognized by Clang as well. Let's rip off the cc-option / cc-disable-warning switches. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com>
2018-11-03Merge tag 'kbuild-v4.20-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - clean-up leftovers in Kconfig files - remove stale oldnoconfig and silentoldconfig targets - remove unneeded cc-fullversion and cc-name variables - improve merge_config script to allow overriding option prefix * tag 'kbuild-v4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: remove cc-name variable kbuild: replace cc-name test with CONFIG_CC_IS_CLANG merge_config.sh: Allow to define config prefix kbuild: remove unused cc-fullversion variable kconfig: remove silentoldconfig target kconfig: remove oldnoconfig target powerpc: PCI_MSI needs PCI powerpc: remove CONFIG_MCA leftovers powerpc: remove CONFIG_PCI_QSPAN scsi: aha152x: rename the PCMCIA define
2018-11-02kbuild: replace cc-name test with CONFIG_CC_IS_CLANGMasahiro Yamada
Evaluating cc-name invokes the compiler every time even when you are not compiling anything, like 'make help'. This is not efficient. The compiler type has been already detected in the Kconfig stage. Use CONFIG_CC_IS_CLANG, instead. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Acked-by: Paul Burton <paul.burton@mips.com> (MIPS) Acked-by: Joel Stanley <joel@jms.id.au>
2018-11-01Merge tag 'compiler-attributes-for-linus-4.20-rc1' of ↵Linus Torvalds
https://github.com/ojeda/linux Pull compiler attribute updates from Miguel Ojeda: "This is an effort to disentangle the include/linux/compiler*.h headers and bring them up to date. The main idea behind the series is to use feature checking macros (i.e. __has_attribute) instead of compiler version checks (e.g. GCC_VERSION), which are compiler-agnostic (so they can be shared, reducing the size of compiler-specific headers) and version-agnostic. Other related improvements have been performed in the headers as well, which on top of the use of __has_attribute it has amounted to a significant simplification of these headers (e.g. GCC_VERSION is now only guarding a few non-attribute macros). This series should also help the efforts to support compiling the kernel with clang and icc. A fair amount of documentation and comments have also been added, clarified or removed; and the headers are now more readable, which should help kernel developers in general. The series was triggered due to the move to gcc >= 4.6. In turn, this series has also triggered Sparse to gain the ability to recognize __has_attribute on its own. Finally, the __nonstring variable attribute series has been also applied on top; plus two related patches from Nick Desaulniers for unreachable() that came a bit afterwards" * tag 'compiler-attributes-for-linus-4.20-rc1' of https://github.com/ojeda/linux: compiler-gcc: remove comment about gcc 4.5 from unreachable() compiler.h: update definition of unreachable() Compiler Attributes: ext4: remove local __nonstring definition Compiler Attributes: auxdisplay: panel: use __nonstring Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8) Compiler Attributes: add support for __nonstring (gcc >= 8) Compiler Attributes: add MAINTAINERS entry Compiler Attributes: add Doc/process/programming-language.rst Compiler Attributes: remove uses of __attribute__ from compiler.h Compiler Attributes: KENTRY used twice the "used" attribute Compiler Attributes: use feature checks instead of version checks Compiler Attributes: add missing SPDX ID in compiler_types.h Compiler Attributes: remove unneeded sparse (__CHECKER__) tests Compiler Attributes: homogenize __must_be_array Compiler Attributes: remove unneeded tests Compiler Attributes: always use the extra-underscores syntax Compiler Attributes: remove unused attributes
2018-10-11Makefile: Globally enable VLA warningKees Cook
Now that Variable Length Arrays (VLAs) have been entirely removed[1] from the kernel, enable the VLA warning globally. The only exceptions to this are the KASan an UBSan tests which are explicitly checking that VLAs trigger their respective tests. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: David Airlie <airlied@linux.ie> Cc: linux-kbuild@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kees Cook <keescook@chromium.org>
2018-09-30Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8)Miguel Ojeda
Commit 217c3e019675 ("disable stringop truncation warnings for now") disabled -Wstringop-truncation since it was too noisy. Having __nonstring available allows us to let GCC know that a string is not meant to be NUL-terminated, which helps suppressing some -Wstringop-truncation warnings. Note that using __nonstring actually triggers other warnings (-Wstringop-overflow, which is on by default) which may be real problems. Therefore, cleaning up -Wstringop-truncation warnings also buys us the ability to uncover further potential problems. To encourage the use of __nonstring, we put the warning back at W=1. In the future, if we end up with a fairly warning-free tree, we might want to enable it by default. Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # on top of v4.19-rc5, clang 7 Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
2018-01-18Kbuild: suppress packed-not-aligned warning for default setting onlyXiongfeng Wang
gcc-8 reports many -Wpacked-not-aligned warnings. The below are some examples. ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct ceph_entity_addr' is less than 8 [-Wpacked-not-aligned] } __attribute__ ((packed)); ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct ceph_entity_addr' is less than 8 [-Wpacked-not-aligned] } __attribute__ ((packed)); ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct ceph_entity_addr' is less than 8 [-Wpacked-not-aligned] } __attribute__ ((packed)); This patch suppresses this kind of warnings for default setting. Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-01Kbuild: enable -Wunused-macros warning for "make W=2"Johannes Thumshirn
We have lots of dead defines and macros in drivers, lets offer users a way to detect and eventually remove them. Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-04-23kbuild: drop -Wno-unknown-warning-option from clang optionsMasahiro Yamada
Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"), cc-option and friends work nicely for clang. However, -Wno-unknown-warning-option makes clang happy with any unknown warning options even if -Werror is specified. Once -Wno-unknown-warning-option is added, any succeeding call of cc-disable-warning is evaluated positive, then unknown warning options are accepted. This should be dropped. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-11-11Kbuild: enable -Wmaybe-uninitialized warnings by defaultArnd Bergmann
Previously the warnings were added back at the W=1 level and above, this now turns them on again by default, assuming that we have addressed all warnings and again have a clean build for v4.10. I found a number of new warnings in linux-next already and submitted bugfixes for those. Hopefully they are caught by the 0day builder in the future as soon as this patch is merged. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-11-11Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"Arnd Bergmann
Traditionally, we have always had warnings about uninitialized variables enabled, as this is part of -Wall, and generally a good idea [1], but it also always produced false positives, mainly because this is a variation of the halting problem and provably impossible to get right in all cases [2]. Various people have identified cases that are particularly bad for false positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized when building with -Os"), I turned off the warning for any build that was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number of false positive warnings in the default build but unfortunately had the side effect of turning the warning off completely in 'allmodconfig' builds, which in turn led to a lot of warnings (both actual bugs, and remaining false positives) to go in unnoticed. With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE definition") enabled the warning again for allmodconfig builds in v4.7 and in v4.8-rc1, I had finally managed to address all warnings I get in an ARM allmodconfig build and most other maybe-uninitialized warnings for ARM randconfig builds. However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally") was merged at the same time and disabled it completely for all configurations, because of false-positive warnings on x86 that I had not addressed until then. This caused a lot of actual bugs to get merged into mainline, and I sent several dozen patches for these during the v4.9 development cycle. Most of these are actual bugs, some are for correct code that is safe because it is only called under external constraints that make it impossible to run into the case that gcc sees, and in a few cases gcc is just stupid and finds something that can obviously never happen. I have now done a few thousand randconfig builds on x86 and collected all patches that I needed to address every single warning I got (I can provide the combined patch for the other warnings if anyone is interested), so I hope we can get the warning back and let people catch the actual bugs earlier. This reverts the change to disable the warning completely and for now brings it back at the "make W=1" level, so we can get it merged into mainline without introducing false positives. A follow-up patch enables it on all levels unless some configuration option turns it off because of false-positives. Link: https://rusty.ozlabs.org/?p=232 [1] Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-11kbuild: move -Wunused-const-variable to W=1 warning levelArnd Bergmann
gcc-6 started warning by default about variables that are not used anywhere and that are marked 'const', generating many false positives in an allmodconfig build, e.g.: arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=] arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=] drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=] drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=] drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=] drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=] This is similar to the existing -Wunused-but-set-variable warning that was added in an earlier release and that we disable by default now and only enable when W=1 is set, so it makes sense to do the same here. Once we have eliminated the majority of the warnings for both, we can put them back into the default list. We probably want this in backport kernels as well, to allow building them with gcc-6 without introducing extra warnings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Lee Jones <lee.jones@linaro.org> Cc: stable@vger.kernel.org Signed-off-by: Michal Marek <mmarek@suse.com>
2016-01-12kbuild: Demote 'sign-compare' warning to W=2Lee Jones
Ideally, a kernel compile with W=1 enabled should complete cleanly; however, when we run one currently we are presented with ~25k warnings. 'sign-compare' accounts for ~22k of those ~25k. In this patch we're demoting 'sign-compare' warnings to W=2, with a view to fixing the remaining 3k W=1 warnings required for a clean build. Arnd adds: "As per our discussion, I'd add that this was inadvertedly introduced by Behan when he moved the clang specific warnings into an ifdef block and did not notice that -Wsign-compare was interpreted by both gcc and clang. Earlier, it was introduced in just the same way by Jan-Simon as part of 3d3d6b847420 ("kbuild: LLVMLinux: Adapt warnings for compilation with clang")." Acked-by: Arnd Bergmann <arnd@arndb.de> Fixes: 26ea6bb1fef0 ("kbuild, LLVMLinux: Supress warnings unless W=1-3") Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Michal Marek <mmarek@suse.com>