Makefile.extrawarn: re-enable -Wformat for clang; take 2

-Wformat was recently re-enabled for builds with clang, then quickly
re-disabled, due to concerns stemming from the frequency of default
argu

Makefile.extrawarn: re-enable -Wformat for clang; take 2

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

show more ...

scripts/Makefile.extrawarn: Do not disable clang's -Wformat-zero-length

There are no instances of this warning in the tree across several
difference architectures and configurations. This was added

scripts/Makefile.extrawarn: Do not disable clang's -Wformat-zero-length

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

show more ...

Revert "Makefile.extrawarn: re-enable -Wformat for clang"

This reverts commit 258fafcd0683d9ccfa524129d489948ab3ddc24c.

The clang -Wformat warning is terminally broken, and the clang people
can't s

Revert "Makefile.extrawarn: re-enable -Wformat for clang"

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) <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

Makefile.extrawarn: re-enable -Wformat for clang

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 i

Makefile.extrawarn: re-enable -Wformat for clang

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

show more ...

kbuild: support W=e to make build abort in case of warning

When developing new code/feature, CONFIG_WERROR is most
often turned off, especially for people using make W=12 to
get more warnings.

In s

kbuild: support W=e to make build abort in case of warning

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

show more ...

Kbuild: add -Wno-shift-negative-value where -Wextra is used

As a preparation for moving to -std=gnu11, turn off the
-Wshift-negative-value option. This warning is enabled by gcc when
building with -

Kbuild: add -Wno-shift-negative-value where -Wextra is used

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 <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Sedat Dilek <[email protected]> # LLVM/Clang v13.0.0 (x86-64)
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

Makefile.extrawarn: Move -Wunaligned-access to W=1

-Wunaligned-access is a new warning in clang that is default enabled for
arm and arm64 under certain circumstances within the clang frontend (see
L

Makefile.extrawarn: Move -Wunaligned-access to W=1

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

show more ...

Makefile.extrawarn: remove -Wnested-externs warning

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,

Makefile.extrawarn: remove -Wnested-externs warning

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

show more ...

Makefile.extrawarn: move -Wcast-align to W=3

This warning behaves differently depending on the architecture
and compiler. Using x86 gcc, we get no output at all because
gcc knows the architecture ca

Makefile.extrawarn: move -Wcast-align to W=3

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

show more ...

Makefile.extrawarn: Move sign-compare from W=2 to W=3

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 desc

Makefile.extrawarn: Move sign-compare from W=2 to W=3

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

show more ...

kbuild: Move -Wtype-limits to W=2

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

kbuild: Move -Wtype-limits to W=2

-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 <[email protected]>
Suggested-by: Arnd Bergmann <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

kbuild: Enable -Wtautological-compare

Currently, we disable -Wtautological-compare, which in turn disables a
bunch of more specific tautological comparison warnings that are useful
for the kernel su

kbuild: Enable -Wtautological-compare

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

show more ...

kbuild: Disable -Wpointer-to-enum-cast

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

kbuild: Disable -Wpointer-to-enum-cast

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: [email protected]
Link: https://github.com/ClangBuiltLinux/linux/issues/887
Link: https://github.com/llvm/llvm-project/commit/2a41b31fcdfcb67ab7038fc2ffb606fd50b83a84
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: allow Clang to find unused static inline functions for W=1 build

GCC and Clang have different policy for -Wunused-function; GCC does not
warn unused static inline functions at all whereas Cl

kbuild: allow Clang to find unused static inline functions for W=1 build

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

show more ...

kbuild: rename KBUILD_ENABLE_EXTRA_GCC_CHECKS to KBUILD_EXTRA_WARN

KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning
options for GCC, but now it is a historical misnomer since

kbuild: rename KBUILD_ENABLE_EXTRA_GCC_CHECKS to KBUILD_EXTRA_WARN

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

show more ...

kbuild: refactor scripts/Makefile.extrawarn

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

kbuild: refactor scripts/Makefile.extrawarn

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 <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Sedat Dilek <[email protected]>
Acked-by: Nick Desaulniers <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>

show more ...

kbuild: Remove unnecessary -Wno-unused-value

This flag turns off several other warnings that would
be useful. Most notably -warn_unused_result is disabled.
All of the following warnings are currentl

kbuild: Remove unnecessary -Wno-unused-value

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 <[email protected]>
Cc: [email protected]
Link: https://github.com/ClangBuiltLinux/linux/issues/520
Signed-off-by: Nathan Huckleberry <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: Enable -Wuninitialized

This helps fine very dodgy behavior through both -Wuninitialized
(warning that a variable is always uninitialized) and
-Wsometimes-uninitialized (warning that a variab

kbuild: Enable -Wuninitialized

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

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

show more ...

kbuild: Remove -Waggregate-return from scripts/Makefile.extrawarn

It makes little sense to pass -Waggregate-return these days since large
part of the linux kernel rely on returning struct(s). For in

kbuild: Remove -Waggregate-return from scripts/Makefile.extrawarn

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

show more ...

kbuild: add all Clang-specific flags unconditionally

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_C

kbuild: add all Clang-specific flags unconditionally

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 <[email protected]>
Reviewed-by: Sedat Dilek <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>

show more ...

kbuild: add some extra warning flags unconditionally

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.

Si

kbuild: add some extra warning flags unconditionally

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

show more ...

kbuild: replace cc-name test with CONFIG_CC_IS_CLANG

Evaluating cc-name invokes the compiler every time even when you are
not compiling anything, like 'make help'. This is not efficient.

The compil

kbuild: replace cc-name test with CONFIG_CC_IS_CLANG

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 <[email protected]>
Acked-by: Michael Ellerman <[email protected]> (powerpc)
Acked-by: Paul Burton <[email protected]> (MIPS)
Acked-by: Joel Stanley <[email protected]>

show more ...

Makefile: Globally enable VLA warning

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

Makefile: Globally enable VLA warning

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 <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: David Airlie <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Kees Cook <[email protected]>

show more ...

Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8)

Commit 217c3e019675 ("disable stringop truncation warnings for now")
disabled -Wstringop-truncation since it was too noisy.

Havin

Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8)

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 <[email protected]> # on top of v4.19-rc5, clang 7
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Reviewed-by: Luc Van Oostenryck <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

Kbuild: suppress packed-not-aligned warning for default setting only

gcc-8 reports many -Wpacked-not-aligned warnings. The below are some
examples.

./include/linux/ceph/msgr.h:67:1: warning: alignm

Kbuild: suppress packed-not-aligned warning for default setting only

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

show more ...