* [PATCH AUTOSEL 5.4 03/49] Makefile: disallow data races on gcc-10 as well
2020-05-14 18:52 [PATCH AUTOSEL 5.4 01/49] kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check Sasha Levin
@ 2020-05-14 18:52 ` Sasha Levin
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 41/49] Stop the ad-hoc games with -Wno-maybe-initialized Sasha Levin
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Sasha Levin @ 2020-05-14 18:52 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sergei Trofimovich, Jiri Kosina, Masahiro Yamada, Sasha Levin,
linux-kbuild
From: Sergei Trofimovich <slyfox@gentoo.org>
[ Upstream commit b1112139a103b4b1101d0d2d72931f2d33d8c978 ]
gcc-10 will rename --param=allow-store-data-races=0
to -fno-allow-store-data-races.
The flag change happened at https://gcc.gnu.org/PR92046.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 54dd58bc60712..388b7b49a52d0 100644
--- a/Makefile
+++ b/Makefile
@@ -713,6 +713,7 @@ endif
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
+KBUILD_CFLAGS += $(call cc-option,-fno-allow-store-data-races)
include scripts/Makefile.kcov
include scripts/Makefile.gcc-plugins
--
2.20.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH AUTOSEL 5.4 41/49] Stop the ad-hoc games with -Wno-maybe-initialized
2020-05-14 18:52 [PATCH AUTOSEL 5.4 01/49] kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check Sasha Levin
2020-05-14 18:52 ` [PATCH AUTOSEL 5.4 03/49] Makefile: disallow data races on gcc-10 as well Sasha Levin
@ 2020-05-14 18:53 ` Sasha Levin
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 42/49] gcc-10: disable 'zero-length-bounds' warning for now Sasha Levin
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Sasha Levin @ 2020-05-14 18:53 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Linus Torvalds, Sasha Levin, linux-kbuild
From: Linus Torvalds <torvalds@linux-foundation.org>
[ Upstream commit 78a5255ffb6a1af189a83e493d916ba1c54d8c75 ]
We have some rather random rules about when we accept the
"maybe-initialized" warnings, and when we don't.
For example, we consider it unreliable for gcc versions < 4.9, but also
if -O3 is enabled, or if optimizing for size. And then various kernel
config options disabled it, because they know that they trigger that
warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES).
And now gcc-10 seems to be introducing a lot of those warnings too, so
it falls under the same heading as 4.9 did.
At the same time, we have a very straightforward way to _enable_ that
warning when wanted: use "W=2" to enable more warnings.
So stop playing these ad-hoc games, and just disable that warning by
default, with the known and straight-forward "if you want to work on the
extra compiler warnings, use W=123".
Would it be great to have code that is always so obvious that it never
confuses the compiler whether a variable is used initialized or not?
Yes, it would. In a perfect world, the compilers would be smarter, and
our source code would be simpler.
That's currently not the world we live in, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 7 +++----
init/Kconfig | 18 ------------------
kernel/trace/Kconfig | 1 -
3 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/Makefile b/Makefile
index 388b7b49a52d0..68708ae07fbd3 100644
--- a/Makefile
+++ b/Makefile
@@ -707,10 +707,6 @@ else ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os
endif
-ifdef CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED
-KBUILD_CFLAGS += -Wno-maybe-uninitialized
-endif
-
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
KBUILD_CFLAGS += $(call cc-option,-fno-allow-store-data-races)
@@ -861,6 +857,9 @@ KBUILD_CFLAGS += -Wno-pointer-sign
# disable stringop warnings in gcc 8+
KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
+# Enabled with W=2, disabled by default as noisy
+KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
+
# disable invalid "can't wrap" optimizations for signed / pointers
KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
diff --git a/init/Kconfig b/init/Kconfig
index 0bffc8fdbf3da..6db3e310a5e42 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -36,22 +36,6 @@ config TOOLS_SUPPORT_RELR
config CC_HAS_ASM_INLINE
def_bool $(success,echo 'void foo(void) { asm inline (""); }' | $(CC) -x c - -c -o /dev/null)
-config CC_HAS_WARN_MAYBE_UNINITIALIZED
- def_bool $(cc-option,-Wmaybe-uninitialized)
- help
- GCC >= 4.7 supports this option.
-
-config CC_DISABLE_WARN_MAYBE_UNINITIALIZED
- bool
- depends on CC_HAS_WARN_MAYBE_UNINITIALIZED
- default CC_IS_GCC && GCC_VERSION < 40900 # unreliable for GCC < 4.9
- help
- GCC's -Wmaybe-uninitialized is not reliable by definition.
- Lots of false positive warnings are produced in some cases.
-
- If this option is enabled, -Wno-maybe-uninitialzed is passed
- to the compiler to suppress maybe-uninitialized warnings.
-
config CONSTRUCTORS
bool
depends on !UML
@@ -1226,14 +1210,12 @@ config CC_OPTIMIZE_FOR_PERFORMANCE
config CC_OPTIMIZE_FOR_PERFORMANCE_O3
bool "Optimize more for performance (-O3)"
depends on ARC
- imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives
help
Choosing this option will pass "-O3" to your compiler to optimize
the kernel yet more for performance.
config CC_OPTIMIZE_FOR_SIZE
bool "Optimize for size (-Os)"
- imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives
help
Choosing this option will pass "-Os" to your compiler resulting
in a smaller kernel.
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index e08527f50d2a9..f3f2fc8ad81aa 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -371,7 +371,6 @@ config PROFILE_ANNOTATED_BRANCHES
config PROFILE_ALL_BRANCHES
bool "Profile all if conditionals" if !FORTIFY_SOURCE
select TRACE_BRANCH_PROFILING
- imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives
help
This tracer profiles all branch conditions. Every if ()
taken in the kernel is recorded whether it hit or miss.
--
2.20.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH AUTOSEL 5.4 42/49] gcc-10: disable 'zero-length-bounds' warning for now
2020-05-14 18:52 [PATCH AUTOSEL 5.4 01/49] kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check Sasha Levin
2020-05-14 18:52 ` [PATCH AUTOSEL 5.4 03/49] Makefile: disallow data races on gcc-10 as well Sasha Levin
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 41/49] Stop the ad-hoc games with -Wno-maybe-initialized Sasha Levin
@ 2020-05-14 18:53 ` Sasha Levin
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 43/49] gcc-10: disable 'array-bounds' " Sasha Levin
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Sasha Levin @ 2020-05-14 18:53 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Linus Torvalds, Sasha Levin, linux-kbuild
From: Linus Torvalds <torvalds@linux-foundation.org>
[ Upstream commit 5c45de21a2223fe46cf9488c99a7fbcf01527670 ]
This is a fine warning, but we still have a number of zero-length arrays
in the kernel that come from the traditional gcc extension. Yes, they
are getting converted to flexible arrays, but in the meantime the gcc-10
warning about zero-length bounds is very verbose, and is hiding other
issues.
I missed one actual build failure because it was hidden among hundreds
of lines of warning. Thankfully I caught it on the second go before
pushing things out, but it convinced me that I really need to disable
the new warnings for now.
We'll hopefully be all done with our conversion to flexible arrays in
the not too distant future, and we can then re-enable this warning.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Makefile b/Makefile
index 68708ae07fbd3..49c74e8b55df4 100644
--- a/Makefile
+++ b/Makefile
@@ -857,6 +857,9 @@ KBUILD_CFLAGS += -Wno-pointer-sign
# disable stringop warnings in gcc 8+
KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
+# We'll want to enable this eventually, but it's not going away for 5.7 at least
+KBUILD_CFLAGS += $(call cc-disable-warning, zero-length-bounds)
+
# Enabled with W=2, disabled by default as noisy
KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
--
2.20.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH AUTOSEL 5.4 43/49] gcc-10: disable 'array-bounds' warning for now
2020-05-14 18:52 [PATCH AUTOSEL 5.4 01/49] kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check Sasha Levin
` (2 preceding siblings ...)
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 42/49] gcc-10: disable 'zero-length-bounds' warning for now Sasha Levin
@ 2020-05-14 18:53 ` Sasha Levin
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 44/49] gcc-10: disable 'stringop-overflow' " Sasha Levin
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 45/49] gcc-10: disable 'restrict' " Sasha Levin
5 siblings, 0 replies; 7+ messages in thread
From: Sasha Levin @ 2020-05-14 18:53 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Linus Torvalds, Sasha Levin, linux-kbuild
From: Linus Torvalds <torvalds@linux-foundation.org>
[ Upstream commit 44720996e2d79e47d508b0abe99b931a726a3197 ]
This is another fine warning, related to the 'zero-length-bounds' one,
but hitting the same historical code in the kernel.
Because C didn't historically support flexible array members, we have
code that instead uses a one-sized array, the same way we have cases of
zero-sized arrays.
The one-sized arrays come from either not wanting to use the gcc
zero-sized array extension, or from a slight convenience-feature, where
particularly for strings, the size of the structure now includes the
allocation for the final NUL character.
So with a "char name[1];" at the end of a structure, you can do things
like
v = my_malloc(sizeof(struct vendor) + strlen(name));
and avoid the "+1" for the terminator.
Yes, the modern way to do that is with a flexible array, and using
'offsetof()' instead of 'sizeof()', and adding the "+1" by hand. That
also technically gets the size "more correct" in that it avoids any
alignment (and thus padding) issues, but this is another long-term
cleanup thing that will not happen for 5.7.
So disable the warning for now, even though it's potentially quite
useful. Having a slew of warnings that then hide more urgent new issues
is not an improvement.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 49c74e8b55df4..8c8ad7e25e15e 100644
--- a/Makefile
+++ b/Makefile
@@ -859,6 +859,7 @@ KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
# We'll want to enable this eventually, but it's not going away for 5.7 at least
KBUILD_CFLAGS += $(call cc-disable-warning, zero-length-bounds)
+KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds)
# Enabled with W=2, disabled by default as noisy
KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
--
2.20.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH AUTOSEL 5.4 44/49] gcc-10: disable 'stringop-overflow' warning for now
2020-05-14 18:52 [PATCH AUTOSEL 5.4 01/49] kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check Sasha Levin
` (3 preceding siblings ...)
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 43/49] gcc-10: disable 'array-bounds' " Sasha Levin
@ 2020-05-14 18:53 ` Sasha Levin
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 45/49] gcc-10: disable 'restrict' " Sasha Levin
5 siblings, 0 replies; 7+ messages in thread
From: Sasha Levin @ 2020-05-14 18:53 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Linus Torvalds, Sasha Levin, linux-kbuild
From: Linus Torvalds <torvalds@linux-foundation.org>
[ Upstream commit 5a76021c2eff7fcf2f0918a08fd8a37ce7922921 ]
This is the final array bounds warning removal for gcc-10 for now.
Again, the warning is good, and we should re-enable all these warnings
when we have converted all the legacy array declaration cases to
flexible arrays. But in the meantime, it's just noise.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 8c8ad7e25e15e..b557cf8ce3ebc 100644
--- a/Makefile
+++ b/Makefile
@@ -860,6 +860,7 @@ KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
# We'll want to enable this eventually, but it's not going away for 5.7 at least
KBUILD_CFLAGS += $(call cc-disable-warning, zero-length-bounds)
KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds)
+KBUILD_CFLAGS += $(call cc-disable-warning, stringop-overflow)
# Enabled with W=2, disabled by default as noisy
KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
--
2.20.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH AUTOSEL 5.4 45/49] gcc-10: disable 'restrict' warning for now
2020-05-14 18:52 [PATCH AUTOSEL 5.4 01/49] kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check Sasha Levin
` (4 preceding siblings ...)
2020-05-14 18:53 ` [PATCH AUTOSEL 5.4 44/49] gcc-10: disable 'stringop-overflow' " Sasha Levin
@ 2020-05-14 18:53 ` Sasha Levin
5 siblings, 0 replies; 7+ messages in thread
From: Sasha Levin @ 2020-05-14 18:53 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Linus Torvalds, Sasha Levin, linux-kbuild
From: Linus Torvalds <torvalds@linux-foundation.org>
[ Upstream commit adc71920969870dfa54e8f40dac8616284832d02 ]
gcc-10 now warns about passing aliasing pointers to functions that take
restricted pointers.
That's actually a great warning, and if we ever start using 'restrict'
in the kernel, it might be quite useful. But right now we don't, and it
turns out that the only thing this warns about is an idiom where we have
declared a few functions to be "printf-like" (which seems to make gcc
pick up the restricted pointer thing), and then we print to the same
buffer that we also use as an input.
And people do that as an odd concatenation pattern, with code like this:
#define sysfs_show_gen_prop(buffer, fmt, ...) \
snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)
where we have 'buffer' as both the destination of the final result, and
as the initial argument.
Yes, it's a bit questionable. And outside of the kernel, people do have
standard declarations like
int snprintf( char *restrict buffer, size_t bufsz,
const char *restrict format, ... );
where that output buffer is marked as a restrict pointer that cannot
alias with any other arguments.
But in the context of the kernel, that 'use snprintf() to concatenate to
the end result' does work, and the pattern shows up in multiple places.
And we have not marked our own version of snprintf() as taking restrict
pointers, so the warning is incorrect for now, and gcc picks it up on
its own.
If we do start using 'restrict' in the kernel (and it might be a good
idea if people find places where it matters), we'll need to figure out
how to avoid this issue for snprintf and friends. But in the meantime,
this warning is not useful.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Makefile b/Makefile
index b557cf8ce3ebc..a8c9d6d9d8ea5 100644
--- a/Makefile
+++ b/Makefile
@@ -862,6 +862,9 @@ KBUILD_CFLAGS += $(call cc-disable-warning, zero-length-bounds)
KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds)
KBUILD_CFLAGS += $(call cc-disable-warning, stringop-overflow)
+# Another good warning that we'll want to enable eventually
+KBUILD_CFLAGS += $(call cc-disable-warning, restrict)
+
# Enabled with W=2, disabled by default as noisy
KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
--
2.20.1
^ permalink raw reply related [flat|nested] 7+ messages in thread