On Mon, Dec 09, 2024 at 07:45:51AM +0100, Greg Kroah-Hartman wrote: > > 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 > > I don't want this disabled for all files in the kernel, we only have one > that this is a problem for. I think you disable this, the whole fortify > logic is disabled which is not the goal, why not just force the fortify > feature OFF if we have a "bad compiler" that can not support it? I am glad we agree that disabling -Wstringop-overread for the kernel entirely is the wrong way to approach this but I think that turning off ALL of FORTIFY_SOURCE for these compiler versions (which are some of the latest available) is also the wrong approach, especially in this current situation where it seems like it is unreasonable to expect the compiler not to warn about a potential overread here with the amount of information available to it but maybe I am misunderstanding something here: https://lore.kernel.org/20241209193558.GA1597021@ax162/ If it is not possible to shut the compiler up by changing the source to be more robust, I think we should strongly consider disabling it in directly in cpumask_copy() using the __diag infrastructure. I think it is underutilized as a solution to warnings like this. > And it's odd that we are the only 2 people hitting it, has everyone else > just given up on gcc and moved on to using clang? Maybe people are not using CONFIG_WERROR=y and W=e when hitting this so they do not notice? It also only became visible in 6.12 because of the 'inline' -> '__always_inline' changes in bitmap.h and cpumask.h, since prior to that, the size of the objects being passed to memcpy() were not known, so FORTIFY could not catch them (another +1 for that change).
