kbuild: Disable -Wdefault-const-init-unsafe

A new on by default warning in clang [1] aims to flags instances where
const variables without static or thread local storage or const members
in aggregat

kbuild: Disable -Wdefault-const-init-unsafe

A new on by default warning in clang [1] aims to flags instances where
const variables without static or thread local storage or const members
in aggregate types are not initialized because it can lead to an
indeterminate value. This is quite noisy for the kernel due to
instances 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 '= {}' is
not available in older but supported compilers and '= {0}' would cause
warnings about a literal 0 being treated as NULL. While it might be
possible to come up with a local hack to silence the warning for
clang-21+, it may not be worth it since -Wuninitialized will still
trigger if an uninitialized const variable is actually used.

In all audited cases of the "field" variant of the warning, the members
are either not used in the particular call path, modified through other
means such as memset() / memcpy() because the containing object is not
const, 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: [email protected]
Link: https://github.com/llvm/llvm-project/commit/576161cb6069e2c7656a8ef530727a0f4aefff30 [1]
Reported-by: Linux Kernel Functional Testing <[email protected]>
Closes: https://lore.kernel.org/CA+G9fYuNjKcxFKS_MKPRuga32XbndkLGcY-PVuoSwzv6VWbY=w@mail.gmail.com/
Reported-by: Marcus Seyfarth <[email protected]>
Closes: https://github.com/ClangBuiltLinux/linux/issues/2088
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

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

Clang and GCC have different behaviors around disabling warnings
included in -Wall and -Wextra and the order in which flags ar

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

Clang and GCC have different behaviors around disabling warnings
included in -Wall and -Wextra and the order in which flags are
specified, 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.c

Move -Wextra up right below -Wall in Makefile.extrawarn to ensure these
flags are at the beginning of the warning options list. Move the couple
of warning options that have been added to the main Makefile since
commit e88ca24319e4 ("kbuild: consolidate warning flags in
scripts/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/10359
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

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

This was triggered by one of my mis-uses causing odd build warnings on
sparc in linux-next, but while figuring out why the "obviously correct"
use

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

This was triggered by one of my mis-uses causing odd build warnings on
sparc in linux-next, but while figuring out why the "obviously correct"
use of cc-option caused such odd breakage, I found eight other cases of
the same thing in the tree.

The root cause is that 'cc-option' doesn't work for checking negative
warning options (ie things like '-Wno-stringop-overflow') because gcc
will 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 is
emitted. At that point the compiler will go "Hmm, maybe the user
intended to disable this warning but used that wrong option that I
didn't recognize", and generate a warning for the unrecognized negative
option.

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 the
time it simply doesn't matter that ity doesn't work.

The reason my recently added case caused problems on sparc was pointed
out by Thomas Weißschuh: the sparc build had a previous explicit warning
that then triggered the new one.

I think the best fix for this would be to make 'cc-option' a bit smarter
about this sitation, possibly by adding an intentional warning to the
test case that then triggers the unrecognized option warning reliably.

But the short-term fix is to replace 'cc-option' with an existing helper
designed for this exact case: 'cc-disable-warning', which picks the
negative warning but uses the positive form for testing the compiler
support.

Reported-by: Stephen Rothwell <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/
Explained-by: Thomas Weißschuh <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

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

The -fzero-init-padding-bits=all option is not a warning flag, so
defining it in scripts/Makefile.extrawarn is inconsistent.

Move

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

The -fzero-init-padding-bits=all option is not a warning flag, so
defining it in scripts/Makefile.extrawarn is inconsistent.

Move it to the top-level Makefile for consistency.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Reviewed-by: Kees Cook <[email protected]>

show more ...

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

-Wenum-enum-conversion was strengthened in clang-19 to warn for C, which
caused the kernel to move it to W=1 in commit 75b5ab134bb5 ("kbuild:
Move -Wenum-{

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

-Wenum-enum-conversion was strengthened in clang-19 to warn for C, which
caused the kernel to move it to W=1 in commit 75b5ab134bb5 ("kbuild:
Move -Wenum-{compare-conditional,enum-conversion} into W=1") because
there 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 they
continue to see the numerous instances of this warning.

Since the move to W=1, there have not been many new instances that have
appeared through various build reports and the ones that have appeared
seem to be following similar existing patterns, suggesting that most
instances of this warning will not be real issues. The only alternatives
for silencing this warning are adding casts (which is generally seen as
an ugly practice) or refactoring the enums to macro defines or a unified
enum (which may be undesirable because of type safety in other parts of
the code).

Move the warning to W=2, where warnings that occur frequently but may be
relevant should reside.

Cc: [email protected]
Fixes: 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1")
Link: https://lore.kernel.org/[email protected]/
Signed-off-by: Nathan Chancellor <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

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

Clang's -Wformat-overflow and -Wformat-truncation have chosen to check
'%p' unlike GCC but it does not know about the kern

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

Clang's -Wformat-overflow and -Wformat-truncation have chosen to check
'%p' unlike GCC but it does not know about the kernel's pointer
extensions in lib/vsprintf.c, so the developers split that part of the
warning out for the kernel to disable because there will always be false
positives.

Commit 908dd508276d ("kbuild: enable -Wformat-truncation on clang") did
disabled these warnings but only in a block that would be called when
W=1 was not passed, so they would appear with W=1. Move the disabling of
the non-kprintf warnings to a block that always runs so that they are
never seen, regardless of warning level.

Fixes: 908dd508276d ("kbuild: enable -Wformat-truncation on clang")
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

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

GCC 15 introduces a regression in "= { 0 }" style initialization of
unions that Linux has depended on for eliminating uninitialized variable
contents. GCC do

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

GCC 15 introduces a regression in "= { 0 }" style initialization of
unions that Linux has depended on for eliminating uninitialized variable
contents. 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 will
correctly zero padding bits in unions and structs that might have been
left uninitialized, and will make sure there is no immediate regression
in union initializations. As seen in the stackinit KUnit selftest union
cases, 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: 56

The above all now pass again with -fzero-init-padding-bits=all added.

This also fixes the following cases for struct initialization that had
been XFAIL until now because there was no compiler support beyond the
larger "-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: 7

All of the above now pass when built under GCC 15. Tests can be seen
with:

./tools/testing/kunit/kunit.py run stackinit --arch=x86_64 \
--make_option CC=gcc-15

Clang continues to fully initialize these kinds of variables[3] without
additional flags.

Suggested-by: Jakub Jelinek <[email protected]>
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 <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>

show more ...

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

All known function cast warnings are now addressed, so the warning can be
enabled globally to catch new ones more quickly.

Link: https://l

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

All known function cast warnings are now addressed, so the warning can be
enabled globally to catch new ones more quickly.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicolas Schier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

kbuild: enable -Wformat-truncation on clang

This warning option still produces output on gcc but is now clean when
building with clang, so enable it conditionally on the compiler for now.

As far as

kbuild: enable -Wformat-truncation on clang

This warning option still produces output on gcc but is now clean when
building 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 of
analysing the code more deeply across inlining, while clang only does this
within a function.

Link: https://lore.kernel.org/lkml/[email protected]/
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/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicolas Schier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

kbuild: turn on -Wrestrict by default

All known -Wrestrict warnings are addressed now, so don't disable the
warning any more.

Link: https://lkml.kernel.org/r/[email protected]

kbuild: turn on -Wrestrict by default

All known -Wrestrict warnings are addressed now, so don't disable the
warning any more.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicolas Schier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

kbuild: remove redundant extra warning flags

There is no point in turning individual options off and then on again, or
vice versa, as the last one always wins. Now that -Wextra always gets
passed f

kbuild: remove redundant extra warning flags

There is no point in turning individual options off and then on again, or
vice versa, as the last one always wins. Now that -Wextra always gets
passed first, remove all the redundant lines about warnings that are
implied by either -Wall or -Wextra, and keep only the last one that
disables it in some configurations.

This should not have any effect but keep the Makefile more readable and
the command line shorter.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicolas Schier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

kbuild: turn on -Wextra by default

Patch series "kbuild: enable more warnings by default", v3.

All the warning fixes I sent for these warnings have been merged into
mainline or linux-next, so let's

kbuild: turn on -Wextra by default

Patch series "kbuild: enable more warnings by default", v3.

All the warning fixes I sent for these warnings have been merged into
mainline 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 differ
slightly by compiler version. Some are useful in general, others are
better left at W=1 or higher. Based on earlier work, the ones that should
be disabled by default are left for the higher warning levels already, and
a lot of the useful ones have no remaining output when enabled.

Move the -Wextra option up into the set of default-enabled warnings and
just rely on the individual ones getting disabled as needed.

The -Wunused warning was always grouped with this, so turn it on by
default as well, except for the -Wunused-parameter warning that really has
no value at all for the kernel since many interfaces have intentionally
unused arguments.

Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Nathan Chancellor <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Nicolas Schier <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

kbuild: make -Woverride-init warnings more consistent

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
disagr

kbuild: make -Woverride-init warnings more consistent

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 <[email protected]>
Acked-by: Hamza Mahfooz <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Acked-by: Andrew Jeffery <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

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

Commit 4a5838ad9d2d ("kbuild: Add extra gcc checks") added the
-Wpacked-bitfield-compat flag, but there is no need to add it
explicitly.

G

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

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 <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>

show more ...

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

Clang enables -Wenum-enum-conversion and -Wenum-compare-conditional
under -Wenum-conversion. A recent change in Clang strengthened

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

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: [email protected]
Closes: https://github.com/ClangBuiltLinux/linux/issues/2002
Link: https://github.com/llvm/llvm-project/commit/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e
Acked-by: Yonghong Song <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

Makefile: Enable -Wstringop-overflow globally

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 o

Makefile: Enable -Wstringop-overflow globally

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 <[email protected]>

show more ...

Makefile.extrawarn: turn on missing-prototypes globally

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 comp

Makefile.extrawarn: turn on missing-prototypes globally

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/[email protected]
Link: https://lore.kernel.org/lkml/[email protected]/
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]> # RISC-V
Cc: Richard Henderson <[email protected]>
Cc: Ivan Kokshaysky <[email protected]>
Cc: Matt Turner <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Thomas Bogendoerfer <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: David Woodhouse <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicolas Schier <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Cc: Tudor Ambarus <[email protected]>
Cc: Zhihao Cheng <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

kbuild: support W=c and W=e shorthands for Kconfig

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

kbuild: support W=c and W=e shorthands for Kconfig

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 <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>

show more ...

extrawarn: move -Wrestrict into W=1 warnings

There are few of these, so enable them whenever W=1 is enabled.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Masahiro Yamada <masahiroy@k

extrawarn: move -Wrestrict into W=1 warnings

There are few of these, so enable them whenever W=1 is enabled.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

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

The stringop and format warnings got disabled globally when they were
newly introduced in commit bd664f6b3e376 ("disable new gcc-7.1.1

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

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 <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: avoid duplicate warning options

Some warning options are disabled at one place and then conditionally
re-enabled later in scripts/Makefile.extrawarn.

For consistency, rework this file so ea

kbuild: avoid duplicate warning options

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 <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: consolidate warning flags in scripts/Makefile.extrawarn

Warning options are enabled and disabled in inconsistent ways and
inconsistent locations. Start rearranging those by moving all option

kbuild: consolidate warning flags in scripts/Makefile.extrawarn

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 <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: add -Wundef to KBUILD_CPPFLAGS for W=1 builds

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 -Wu

kbuild: add -Wundef to KBUILD_CPPFLAGS for W=1 builds

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/[email protected]/

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>

show more ...

Makefile.extrawarn: Move -Wcast-function-type-strict to W=1

We enable -Wcast-function-type globally in the kernel to warn about
mismatching types in function pointer casts. Compilers currently
warn

Makefile.extrawarn: Move -Wcast-function-type-strict to W=1

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: [email protected]
Link: https://reviews.llvm.org/D134831
Link: https://github.com/ClangBuiltLinux/linux/issues/1724
Suggested-by: Nathan Chancellor <[email protected]>
Signed-off-by: Sami Tolvanen <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

Makefile.compiler: replace cc-ifversion with compiler-specific macros

cc-ifversion is GCC specific. Replace it with compiler specific
variants. Update the users of cc-ifversion to use these new macr

Makefile.compiler: replace cc-ifversion with compiler-specific macros

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 <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...