Changes in Makefile.extrawarn

d0afcfeb - kbuild: Disable -Wdefault-const-init-unsafe

Tue, 06 May 2025 21:02:01 +0000

kbuild: Disable -Wdefault-const-init-unsafeA new on by default warning in clang [1] aims to flags instances whereconst variables without static or thread local storage or const membersin aggregate types are not initialized because it can lead to anindeterminate value. This is quite noisy for the kernel due toinstances originating from header files such as: drivers/gpu/drm/i915/gt/intel_ring.h:62:2: error: default initialization of an object of type 'typeof (ring->size)' (aka 'const unsigned int') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe] 62 | typecheck(typeof(ring->size), next); | ^ include/linux/typecheck.h:10:9: note: expanded from macro 'typecheck' 10 | ({ type __dummy; \ | ^ include/net/ip.h:478:14: error: default initialization of an object of type 'typeof (rt->dst.expires)' (aka 'const unsigned long') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe] 478 | if (mtu && time_before(jiffies, rt->dst.expires)) | ^ include/linux/jiffies.h:138:26: note: expanded from macro 'time_before' 138 | #define time_before(a,b) time_after(b,a) | ^ include/linux/jiffies.h:128:3: note: expanded from macro 'time_after' 128 | (typecheck(unsigned long, a) && \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ include/linux/list.h:409:27: warning: default initialization of an object of type 'union (unnamed union at include/linux/list.h:409:27)' with const member leaves the object uninitialized [-Wdefault-const-init-field-unsafe] 409 | struct list_head *next = smp_load_acquire(&head->next); | ^ include/asm-generic/barrier.h:176:29: note: expanded from macro 'smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^ arch/arm64/include/asm/barrier.h:164:59: note: expanded from macro '__smp_load_acquire' 164 | union { __unqual_scalar_typeof(*p) __val; char __c[1]; } __u; \ | ^ include/linux/list.h:409:27: note: member '__val' declared 'const' here crypto/scatterwalk.c:66:22: error: default initialization of an object of type 'struct scatter_walk' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 66 | struct scatter_walk walk; | ^ include/crypto/algapi.h:112:15: note: member 'addr' declared 'const' here 112 | void *const addr; | ^ fs/hugetlbfs/inode.c:733:24: error: default initialization of an object of type 'struct vm_area_struct' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 733 | struct vm_area_struct pseudo_vma; | ^ include/linux/mm_types.h:803:20: note: member 'vm_flags' declared 'const' here 803 | const vm_flags_t vm_flags; | ^Silencing the instances from typecheck.h is difficult because '= {}' isnot available in older but supported compilers and '= {0}' would causewarnings about a literal 0 being treated as NULL. While it might bepossible to come up with a local hack to silence the warning forclang-21+, it may not be worth it since -Wuninitialized will stilltrigger if an uninitialized const variable is actually used.In all audited cases of the "field" variant of the warning, the membersare either not used in the particular call path, modified through othermeans such as memset() / memcpy() because the containing object is notconst, or are within a union with other non-const members.Since this warning does not appear to have a high signal to noise ratio,just disable it.Cc: stable@vger.kernel.orgLink: https://github.com/llvm/llvm-project/commit/576161cb6069e2c7656a8ef530727a0f4aefff30 [1]Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/CA+G9fYuNjKcxFKS_MKPRuga32XbndkLGcY-PVuoSwzv6VWbY=w@mail.gmail.com/Reported-by: Marcus Seyfarth Closes: https://github.com/ClangBuiltLinux/linux/issues/2088Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada List of files: /linux-6.15/scripts/Makefile.extrawarn

4f79eaa2 - kbuild: Properly disable -Wunterminated-string-initialization for clang

Wed, 30 Apr 2025 22:56:34 +0000

kbuild: Properly disable -Wunterminated-string-initialization for clangClang and GCC have different behaviors around disabling warningsincluded in -Wall and -Wextra and the order in which flags arespecified, which is exposed by clang's new support for-Wunterminated-string-initialization. $ cat test.c const char foo[3] = "FOO"; const char bar[3] __attribute__((__nonstring__)) = "BAR"; $ clang -fsyntax-only -Wextra test.c test.c:1:21: warning: initializer-string for character array is too long, array size is 3 but initializer has size 4 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization] 1 | const char foo[3] = "FOO"; | ^~~~~ $ clang -fsyntax-only -Wextra -Wno-unterminated-string-initialization test.c $ clang -fsyntax-only -Wno-unterminated-string-initialization -Wextra test.c test.c:1:21: warning: initializer-string for character array is too long, array size is 3 but initializer has size 4 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization] 1 | const char foo[3] = "FOO"; | ^~~~~ $ gcc -fsyntax-only -Wextra test.c test.c:1:21: warning: initializer-string for array of ‘char’ truncates NUL terminator but destination lacks ‘nonstring’ attribute (4 chars into 3 available) [-Wunterminated-string-initialization] 1 | const char foo[3] = "FOO"; | ^~~~~ $ gcc -fsyntax-only -Wextra -Wno-unterminated-string-initialization test.c $ gcc -fsyntax-only -Wno-unterminated-string-initialization -Wextra test.cMove -Wextra up right below -Wall in Makefile.extrawarn to ensure theseflags are at the beginning of the warning options list. Move the coupleof warning options that have been added to the main Makefile sincecommit e88ca24319e4 ("kbuild: consolidate warning flags inscripts/Makefile.extrawarn") to scripts/Makefile.extrawarn after -Wall /-Wextra to ensure they get properly disabled for all compilers.Fixes: 9d7a0577c9db ("gcc-15: disable '-Wunterminated-string-initialization' entirely for now")Link: https://github.com/llvm/llvm-project/issues/10359Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds List of files: /linux-6.15/scripts/Makefile.extrawarn

a79be02b - Fix mis-uses of 'cc-option' for warning disablement

Wed, 23 Apr 2025 17:08:29 +0000

Fix mis-uses of 'cc-option' for warning disablementThis was triggered by one of my mis-uses causing odd build warnings onsparc in linux-next, but while figuring out why the "obviously correct"use of cc-option caused such odd breakage, I found eight other cases ofthe same thing in the tree.The root cause is that 'cc-option' doesn't work for checking negativewarning options (ie things like '-Wno-stringop-overflow') because gccwill silently accept options it doesn't recognize, and so 'cc-option'ends up thinking they are perfectly fine.And it all works, until you have a situation where _another_ warning isemitted. At that point the compiler will go "Hmm, maybe the userintended to disable this warning but used that wrong option that Ididn't recognize", and generate a warning for the unrecognized negativeoption.Which explains why we have several cases of this in the tree: the'cc-option' test really doesn't work for this situation, but most of thetime it simply doesn't matter that ity doesn't work.The reason my recently added case caused problems on sparc was pointedout by Thomas Weißschuh: the sparc build had a previous explicit warningthat then triggered the new one.I think the best fix for this would be to make 'cc-option' a bit smarterabout this sitation, possibly by adding an intentional warning to thetest case that then triggers the unrecognized option warning reliably.But the short-term fix is to replace 'cc-option' with an existing helperdesigned for this exact case: 'cc-disable-warning', which picks thenegative warning but uses the positive form for testing the compilersupport.Reported-by: Stephen Rothwell Link: https://lore.kernel.org/all/20250422204718.0b4e3f81@canb.auug.org.au/Explained-by: Thomas Weißschuh Signed-off-by: Linus Torvalds List of files: /linux-6.15/scripts/Makefile.extrawarn

c1525349 - kbuild: move -fzero-init-padding-bits=all to the top-level Makefile

Sat, 15 Feb 2025 16:15:52 +0000

kbuild: move -fzero-init-padding-bits=all to the top-level MakefileThe -fzero-init-padding-bits=all option is not a warning flag, sodefining it in scripts/Makefile.extrawarn is inconsistent.Move it to the top-level Makefile for consistency.Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Reviewed-by: Kees Cook List of files: /linux-6.15/scripts/Makefile.extrawarn

8f6629c0 - kbuild: Move -Wenum-enum-conversion to W=2

Thu, 17 Oct 2024 17:09:22 +0000

kbuild: Move -Wenum-enum-conversion to W=2-Wenum-enum-conversion was strengthened in clang-19 to warn for C, whichcaused the kernel to move it to W=1 in commit 75b5ab134bb5 ("kbuild:Move -Wenum-{compare-conditional,enum-conversion} into W=1") becausethere were numerous instances that would break builds with -Werror.Unfortunately, this is not a full solution, as more and more developers,subsystems, and distributors are building with W=1 as well, so theycontinue to see the numerous instances of this warning.Since the move to W=1, there have not been many new instances that haveappeared through various build reports and the ones that have appearedseem to be following similar existing patterns, suggesting that mostinstances of this warning will not be real issues. The only alternativesfor silencing this warning are adding casts (which is generally seen asan ugly practice) or refactoring the enums to macro defines or a unifiedenum (which may be undesirable because of type safety in other parts ofthe code).Move the warning to W=2, where warnings that occur frequently but may berelevant should reside.Cc: stable@vger.kernel.orgFixes: 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1")Link: https://lore.kernel.org/ZwRA9SOcOjjLJcpi@google.com/Signed-off-by: Nathan Chancellor Acked-by: Arnd Bergmann Signed-off-by: Linus Torvalds List of files: /linux-6.15/scripts/Makefile.extrawarn

738fc998 - scripts/Makefile.extrawarn: Do not show clang's non-kprintf warnings at W=1

Fri, 31 Jan 2025 22:55:28 +0000

scripts/Makefile.extrawarn: Do not show clang's non-kprintf warnings at W=1Clang's -Wformat-overflow and -Wformat-truncation have chosen to check'%p' unlike GCC but it does not know about the kernel's pointerextensions in lib/vsprintf.c, so the developers split that part of thewarning out for the kernel to disable because there will always be falsepositives.Commit 908dd508276d ("kbuild: enable -Wformat-truncation on clang") diddisabled these warnings but only in a block that would be called whenW=1 was not passed, so they would appear with W=1. Move the disabling ofthe non-kprintf warnings to a block that always runs so that they arenever seen, regardless of warning level.Fixes: 908dd508276d ("kbuild: enable -Wformat-truncation on clang")Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202501291646.VtwF98qd-lkp@intel.com/Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada List of files: /linux-6.15/scripts/Makefile.extrawarn

dce4aab8 - kbuild: Use -fzero-init-padding-bits=all

Mon, 27 Jan 2025 19:10:28 +0000

kbuild: Use -fzero-init-padding-bits=allGCC 15 introduces a regression in "= { 0 }" style initialization ofunions that Linux has depended on for eliminating uninitialized variablecontents. GCC does not seem likely to fix it[1], instead suggesting[2]that affected projects start using -fzero-init-padding-bits=unions.To avoid future surprises beyond just the current situation with unions,enable -fzero-init-padding-bits=all when available (GCC 15+). This willcorrectly zero padding bits in unions and structs that might have beenleft uninitialized, and will make sure there is no immediate regressionin union initializations. As seen in the stackinit KUnit selftest unioncases, which were passing before, were failing under GCC 15: not ok 18 test_small_start_old_zero ok 29 test_small_start_dynamic_partial # SKIP XFAIL uninit bytes: 63 ok 32 test_small_start_assigned_dynamic_partial # SKIP XFAIL uninit bytes: 63 ok 67 test_small_start_static_partial # SKIP XFAIL uninit bytes: 63 ok 70 test_small_start_static_all # SKIP XFAIL uninit bytes: 56 ok 73 test_small_start_dynamic_all # SKIP XFAIL uninit bytes: 56 ok 82 test_small_start_assigned_static_partial # SKIP XFAIL uninit bytes: 63 ok 85 test_small_start_assigned_static_all # SKIP XFAIL uninit bytes: 56 ok 88 test_small_start_assigned_dynamic_all # SKIP XFAIL uninit bytes: 56The above all now pass again with -fzero-init-padding-bits=all added.This also fixes the following cases for struct initialization that hadbeen XFAIL until now because there was no compiler support beyond thelarger "-ftrivial-auto-var-init=zero" option: ok 38 test_small_hole_static_all # SKIP XFAIL uninit bytes: 3 ok 39 test_big_hole_static_all # SKIP XFAIL uninit bytes: 124 ok 40 test_trailing_hole_static_all # SKIP XFAIL uninit bytes: 7 ok 42 test_small_hole_dynamic_all # SKIP XFAIL uninit bytes: 3 ok 43 test_big_hole_dynamic_all # SKIP XFAIL uninit bytes: 124 ok 44 test_trailing_hole_dynamic_all # SKIP XFAIL uninit bytes: 7 ok 58 test_small_hole_assigned_static_all # SKIP XFAIL uninit bytes: 3 ok 59 test_big_hole_assigned_static_all # SKIP XFAIL uninit bytes: 124 ok 60 test_trailing_hole_assigned_static_all # SKIP XFAIL uninit bytes: 7 ok 62 test_small_hole_assigned_dynamic_all # SKIP XFAIL uninit bytes: 3 ok 63 test_big_hole_assigned_dynamic_all # SKIP XFAIL uninit bytes: 124 ok 64 test_trailing_hole_assigned_dynamic_all # SKIP XFAIL uninit bytes: 7All of the above now pass when built under GCC 15. Tests can be seenwith: ./tools/testing/kunit/kunit.py run stackinit --arch=x86_64 \ --make_option CC=gcc-15Clang continues to fully initialize these kinds of variables[3] withoutadditional flags.Suggested-by: Jakub Jelinek Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403 [1]Link: https://lore.kernel.org/linux-toolchains/Z0hRrrNU3Q+ro2T7@tucnak/ [2]Link: https://github.com/llvm/llvm-project/commit/7a086e1b2dc05f54afae3591614feede727601fa [3]Reviewed-by: Nathan Chancellor Acked-by: Masahiro Yamada Link: https://lore.kernel.org/r/20250127191031.245214-3-kees@kernel.orgSigned-off-by: Kees Cook List of files: /linux-6.15/scripts/Makefile.extrawarn

bd2a70e9 - kbuild: enable -Wcast-function-type-strict unconditionally

Mon, 15 Apr 2024 12:20:36 +0000

kbuild: enable -Wcast-function-type-strict unconditionallyAll known function cast warnings are now addressed, so the warning can beenabled globally to catch new ones more quickly.Link: https://lkml.kernel.org/r/20240415122037.1983124-6-arnd@kernel.orgSigned-off-by: Arnd Bergmann Reviewed-by: Kees Cook Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Signed-off-by: Andrew Morton List of files: /linux-6.15/scripts/Makefile.extrawarn

908dd508 - kbuild: enable -Wformat-truncation on clang

Mon, 15 Apr 2024 12:20:35 +0000

kbuild: enable -Wformat-truncation on clangThis warning option still produces output on gcc but is now clean whenbuilding with clang, so enable it conditionally on the compiler for now.As far as I can tell, the remaining warnings with gcc are the result ofanalysing the code more deeply across inlining, while clang only does thiswithin a function.Link: https://lore.kernel.org/lkml/20240326230511.GA2796782@dev-arch.thelio-3990X/Link: https://lore.kernel.org/linux-patches/20231002-disable-wformat-truncation-overflow-non-kprintf-v1-1-35179205c8d9@kernel.org/Link: https://lkml.kernel.org/r/20240415122037.1983124-5-arnd@kernel.orgSigned-off-by: Arnd Bergmann Cc: Kees Cook Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Signed-off-by: Andrew Morton List of files: /linux-6.15/scripts/Makefile.extrawarn

06bb7fc0 - kbuild: turn on -Wrestrict by default

Mon, 15 Apr 2024 12:20:34 +0000

kbuild: turn on -Wrestrict by defaultAll known -Wrestrict warnings are addressed now, so don't disable thewarning any more.Link: https://lkml.kernel.org/r/20240415122037.1983124-4-arnd@kernel.orgSigned-off-by: Arnd Bergmann Cc: Kees Cook Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Signed-off-by: Andrew Morton List of files: /linux-6.15/scripts/Makefile.extrawarn

2c1460d3 - kbuild: remove redundant extra warning flags

Mon, 15 Apr 2024 12:20:33 +0000

kbuild: remove redundant extra warning flagsThere is no point in turning individual options off and then on again, orvice versa, as the last one always wins. Now that -Wextra always getspassed first, remove all the redundant lines about warnings that areimplied by either -Wall or -Wextra, and keep only the last one thatdisables it in some configurations.This should not have any effect but keep the Makefile more readable andthe command line shorter.Link: https://lkml.kernel.org/r/20240415122037.1983124-3-arnd@kernel.orgSigned-off-by: Arnd Bergmann Cc: Kees Cook Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Signed-off-by: Andrew Morton List of files: /linux-6.15/scripts/Makefile.extrawarn

f5982cce - kbuild: turn on -Wextra by default

Mon, 15 Apr 2024 12:20:32 +0000

kbuild: turn on -Wextra by defaultPatch series "kbuild: enable more warnings by default", v3.All the warning fixes I sent for these warnings have been merged intomainline or linux-next, so let's turn them on by default.This patch (of 6):The -Wextra option controls a number of different warnings that differslightly by compiler version. Some are useful in general, others arebetter left at W=1 or higher. Based on earlier work, the ones that shouldbe disabled by default are left for the higher warning levels already, anda lot of the useful ones have no remaining output when enabled.Move the -Wextra option up into the set of default-enabled warnings andjust rely on the individual ones getting disabled as needed.The -Wunused warning was always grouped with this, so turn it on bydefault as well, except for the -Wunused-parameter warning that really hasno value at all for the kernel since many interfaces have intentionallyunused arguments.Link: https://lkml.kernel.org/r/20240415122037.1983124-1-arnd@kernel.orgLink: https://lkml.kernel.org/r/20240415122037.1983124-2-arnd@kernel.orgSigned-off-by: Arnd Bergmann Acked-by: Nathan Chancellor Cc: Kees Cook Cc: Masahiro Yamada Cc: Nicolas Schier Signed-off-by: Andrew Morton List of files: /linux-6.15/scripts/Makefile.extrawarn

c40845e3 - kbuild: make -Woverride-init warnings more consistent

Tue, 26 Mar 2024 14:47:16 +0000

kbuild: make -Woverride-init warnings more consistentThe -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 ofdisagreement on whether this warning option should be enabled by defaultand we have multiple settings in scripts/Makefile.extrawarn as well asindividual subsystems.Older versions of clang only supported -Wno-initializer-overrides withthe same meaning as gcc's -Woverride-init, though all supported versionsnow work with both. Because of this difference, an earlier cleanup ofmine accidentally turned the clang warning off for W=1 builds and onlyleft 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 newerversions of gcc but not other compilers, and some but not all theMakefiles still use a cc-disable-warning conditional that is nolonger needed with supported compilers here.Address all of the above by removing the special cases for clangand always turning the warning off unconditionally where it gotin the way, using the syntax that is supported by both compilers.Fixes: 2cd3271b7a31 ("kbuild: avoid duplicate warning options")Signed-off-by: Arnd Bergmann Acked-by: Hamza Mahfooz Acked-by: Jani Nikula Acked-by: Andrew Jeffery Signed-off-by: Jani Nikula Reviewed-by: Linus Walleij Signed-off-by: Masahiro Yamada List of files: /linux-6.15/scripts/Makefile.extrawarn

44929bfa - kbuild: remove GCC's default -Wpacked-bitfield-compat flag

Wed, 06 Mar 2024 12:47:09 +0000

kbuild: remove GCC's default -Wpacked-bitfield-compat flagCommit 4a5838ad9d2d ("kbuild: Add extra gcc checks") added the-Wpacked-bitfield-compat flag, but there is no need to add itexplicitly.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 Clangbuilds.Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor List of files: /linux-6.15/scripts/Makefile.extrawarn

75b5ab13 - kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1

Tue, 05 Mar 2024 22:12:47 +0000

kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1Clang enables -Wenum-enum-conversion and -Wenum-compare-conditionalunder -Wenum-conversion. A recent change in Clang strengthened thesewarnings and they appear frequently in common builds, primarily due toseveral instances in common headers but there are quite a few driversthat 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 couldbe a bug, so each of the instance of the warning needs to be evaluated.Unfortunately, as mentioned above, there are many instances of thiswarning in many different configurations, which can break the build whenCONFIG_WERROR is enabled.To avoid introducing new instances of the warnings while cleaning up thedisruption for the majority of users, disable these warnings for thedefault build while leaving them on for W=1 builds.Cc: stable@vger.kernel.orgCloses: https://github.com/ClangBuiltLinux/linux/issues/2002Link: https://github.com/llvm/llvm-project/commit/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37eAcked-by: Yonghong Song Signed-off-by: Nathan Chancellor Acked-by: Arnd Bergmann Signed-off-by: Masahiro Yamada List of files: /linux-6.15/scripts/Makefile.extrawarn

113a6186 - Makefile: Enable -Wstringop-overflow globally

Tue, 31 Oct 2023 23:50:11 +0000

Makefile: Enable -Wstringop-overflow globallyIt seems that we have finished addressing all the remainingissues regarding -Wstringop-overflow. So, we are now in goodshape to enable this compiler option globally.Signed-off-by: Gustavo A. R. Silva List of files: /linux-6.15/scripts/Makefile.extrawarn

0fcb7085 - Makefile.extrawarn: turn on missing-prototypes globally

Thu, 23 Nov 2023 11:05:06 +0000

Makefile.extrawarn: turn on missing-prototypes globallyOver the years we went from > 1000 of warnings to under 100 earlier thisyear, and I sent patches to address all the ones that I saw with compiletesting randcom configs on arm64, arm and x86 kernels. This is a reallyuseful warning, as it catches real bugs when there are mismatchedprototypes. 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 errorsor warnings on any configuration of x86, arm and arm64 builds. I alsomade sure that at least both the normal defconfig and an allmodconfigbuild is clean for arc, csky, loongarch, m68k, microblaze, openrisc,parisc, powerpc, riscv, s390, and xtensa, with the respective maintainersdoing most of the patches.At this point, there are five architectures with a number of knownregressions: alpha, nios2, mips, sh and sparc. In the previous version ofthis patch, I had turned off the missing prototype warnings for the 15architectures that still had issues, but since there are only five left, Ithink we can leave the rest to the maintainers (Cc'd here) as well.Link: https://lkml.kernel.org/r/20231123110506.707903-7-arnd@kernel.orgLink: https://lore.kernel.org/lkml/20230810141947.1236730-1-arnd@kernel.org/Signed-off-by: Arnd Bergmann Reviewed-by: Kees Cook Acked-by: Palmer Dabbelt # RISC-VCc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: Dinh Nguyen Cc: Thomas Bogendoerfer Cc: Yoshinori Sato Cc: Rich Felker Cc: John Paul Adrian Glaubitz Cc: "David S. Miller" Cc: David Woodhouse Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Michael Ellerman Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Peter Zijlstra Cc: Richard Weinberger Cc: Stephen Rothwell Cc: Tudor Ambarus Cc: Zhihao Cheng Signed-off-by: Andrew Morton List of files: /linux-6.15/scripts/Makefile.extrawarn

92ef432f - kbuild: support W=c and W=e shorthands for Kconfig

Thu, 23 Nov 2023 09:05:40 +0000

kbuild: support W=c and W=e shorthands for KconfigKCONFIG_WARN_UNKNOWN_SYMBOLS=1 and KCONFIG_WERROR=1 are descriptiveand suitable in scripting, but typing them from the command line canbe tedious.Associate them with KBUILD_EXTRA_WARN (and the W= shorthand).Support a new letter 'c' to enable extra checks in Kconfig. You canstill 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 defconfigcan be shortened to: $ KBUILD_EXTRA_WARN=ce make defconfigor, even shorter: $ make W=ce defconfigSigned-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor List of files: /linux-6.15/scripts/Makefile.extrawarn

26030cb9 - extrawarn: move -Wrestrict into W=1 warnings

Fri, 11 Aug 2023 14:03:24 +0000

extrawarn: move -Wrestrict into W=1 warningsThere are few of these, so enable them whenever W=1 is enabled.Signed-off-by: Arnd Bergmann Signed-off-by: Masahiro Yamada List of files: /linux-6.15/scripts/Makefile.extrawarn

6d4ab2e9 - extrawarn: enable format and stringop overflow warnings in W=1

Fri, 11 Aug 2023 14:03:23 +0000

extrawarn: enable format and stringop overflow warnings in W=1The stringop and format warnings got disabled globally when they werenewly introduced in commit bd664f6b3e376 ("disable new gcc-7.1.1 warningsfor 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 areuseful, and we actually addressed a number of real bugs based onthem, but we never managed to eliminate them all because even thebuild bots using W=1 builds only see the -Wstringop-truncationwarnings that are enabled at that level.Move these into the W=1 section to give them a larger build coverageand actually eliminate them over time.Signed-off-by: Arnd Bergmann Signed-off-by: Masahiro Yamada List of files: /linux-6.15/scripts/Makefile.extrawarn