extern unsigned int nr_cpu_ids;
...
static __always_inline
void bitmap_copy(unsigned long *dst, const unsigned long *src, unsigned
int nbits)
{
unsigned int len = bitmap_size(nbits);
if (small_const_nbits(nbits))
*dst = *src;
else
memcpy(dst, src, len);
}
static __always_inline
void cpumask_copy(struct cpumask *dstp, const struct cpumask *srcp)
{
bitmap_copy(cpumask_bits(dstp), cpumask_bits(srcp), large_cpumask_bits);
}
...
static int __padata_set_cpumasks(struct padata_instance *pinst,
cpumask_var_t pcpumask,
cpumask_var_t cbcpumask)
{
...
cpumask_copy(pinst->cpumask.pcpu, pcpumask);
cpumask_copy(pinst->cpumask.cbcpu, cbcpumask);
...
}
So the above statements expands to:
memcpy(pinst->cpumask.pcpu->bits, pcpumask->bits, nr_cpu_ids)
memcpy(pinst->cpumask.cbcpu->bits, cbcpumask->bits, nr_cpu_ids)
Now the compiler complains about "error: â??__builtin_memcpyâ?? reading
between 257 and 536870904 bytes from a region of size 256". So the
value of nr_cpu_ids which gcc calculated is between 257 and 536870904.
This looks strange and incorrect.
Later similar errors[1] were also observed on x86-64 platform using
gcc-14. Apparently, above errors menifests using gcc-13+ and config
option CONFIG_FORTIFY_SOURCE=y. Moreover, I don't encounter above
error when,
- using gcc 11.x or gcc 12.x or LLVM/Clang compiler
or
- disabling CONFIG_FORTIFY_SOURCE option
So for now, silence above errors globally while using gcc-13+ and
CONFIG_FORTIFY_SOURCE=y. We may later revert this change when we
find root cause of the error. Per this discussion[2], GCC developers
are working to add extra diagnostics and context when this error
menifests and that might help to find the root cause.
[1] https://lore.kernel.org/all/2024120757-lustrous-equinox-77f0@gregkh/
[2] https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666870.html
Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Cc: briannorris@xxxxxxxxxxxx
Cc: yury.norov@xxxxxxxxx
Cc: kees@xxxxxxxxxx
Cc: gustavoars@xxxxxxxxxx
Cc: nathan@xxxxxxxxxx
Cc: steffen.klassert@xxxxxxxxxxx
Cc: daniel.m.jordan@xxxxxxxxxx
Cc: gjoyce@xxxxxxx
Cc: linux-crypto@xxxxxxxxxxxxxxx
Cc: linux@xxxxxxxxxxxxxx
Signed-off-by: Nilay Shroff <nilay@xxxxxxxxxxxxx>
---
Changes from v2:
- Globally disable -Werror-stringop-overread while using gcc-13+ and
FORTIFY_SOURCE (Yury Norov)
- Updated the patch subject line to make it clear that this is
possiblt gcc error and not related to cpumask.
Changes from v1:
- Fix spell error in the commit message (Brian Norris)
- Add commentary around change to note that changes are needed to
avoid false positive on gcc 13+ (Brian Norris)
- Add the kerenl/padata.c file maintainers (Brian Norris)
---
init/Kconfig | 8 ++++++++
scripts/Makefile.extrawarn | 1 +
2 files changed, 9 insertions(+)
diff --git a/init/Kconfig b/init/Kconfig
index a20e6efd3f0f..ff2f54520551 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -920,6 +920,14 @@ config CC_STRINGOP_OVERFLOW
bool
default y if CC_IS_GCC && !CC_NO_STRINGOP_OVERFLOW
+# Currently, disable -Wstringop-overread for gcc-13+ and FORTIFY_SOURCE globally.
+config GCC13_NO_STRINGOP_OVERREAD
+ def_bool y
+
+config CC_NO_STRINGOP_OVERREAD
+ bool
+ default y if CC_IS_GCC && GCC_VERSION >= 130000 && GCC13_NO_STRINGOP_OVERREAD && FORTIFY_SOURCE
+
#
# For architectures that know their GCC __int128 support is sound
#
diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 1d13cecc7cc7..1abd41269fd0 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -27,6 +27,7 @@ endif
KBUILD_CPPFLAGS-$(CONFIG_WERROR) += -Werror
KBUILD_CPPFLAGS += $(KBUILD_CPPFLAGS-y)
KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds
+KBUILD_CFLAGS-$(CONFIG_CC_NO_STRINGOP_OVERREAD) += -Wno-stringop-overread
ifdef CONFIG_CC_IS_CLANG
# The kernel builds with '-std=gnu11' so use of GNU extensions is acceptable.
--
2.45.2
