On Sat, Dec 07, 2024 at 12:43:19PM +0100, Greg KH wrote: > On Thu, Dec 05, 2024 at 06:04:09PM +0530, Nilay Shroff wrote: > > While building the powerpc code using gcc 13, I came across following > > errors generated for kernel/padata.c file: > > > > CC kernel/padata.o > > In file included from ./include/linux/string.h:390, > > from ./arch/powerpc/include/asm/paca.h:16, > > from ./arch/powerpc/include/asm/current.h:13, > > from ./include/linux/thread_info.h:23, > > from ./include/asm-generic/preempt.h:5, > > from ./arch/powerpc/include/generated/asm/preempt.h:1, > > from ./include/linux/preempt.h:79, > > from ./include/linux/spinlock.h:56, > > from ./include/linux/swait.h:7, > > from ./include/linux/completion.h:12, > > from kernel/padata.c:14: > > In function ‘bitmap_copy’, > > inlined from ‘cpumask_copy’ at ./include/linux/cpumask.h:839:2, > > inlined from ‘__padata_set_cpumasks’ at kernel/padata.c:730:2: > > ./include/linux/fortify-string.h:114:33: error: ‘__builtin_memcpy’ reading between 257 and 536870904 bytes from a region of size 256 [-Werror=stringop-overread] > > 114 | #define __underlying_memcpy __builtin_memcpy > > | ^ > > ./include/linux/fortify-string.h:633:9: note: in expansion of macro ‘__underlying_memcpy’ > > 633 | __underlying_##op(p, q, __fortify_size); \ > > | ^~~~~~~~~~~~~ > > ./include/linux/fortify-string.h:678:26: note: in expansion of macro ‘__fortify_memcpy_chk’ > > 678 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ > > | ^~~~~~~~~~~~~~~~~~~~ > > ./include/linux/bitmap.h:259:17: note: in expansion of macro ‘memcpy’ > > 259 | memcpy(dst, src, len); > > | ^~~~~~ > > kernel/padata.c: In function ‘__padata_set_cpumasks’: > > kernel/padata.c:713:48: note: source object ‘pcpumask’ of size [0, 256] > > 713 | cpumask_var_t pcpumask, > > | ~~~~~~~~~~~~~~^~~~~~~~ > > In function ‘bitmap_copy’, > > inlined from ‘cpumask_copy’ at ./include/linux/cpumask.h:839:2, > > inlined from ‘__padata_set_cpumasks’ at kernel/padata.c:730:2: > > ./include/linux/fortify-string.h:114:33: error: ‘__builtin_memcpy’ reading between 257 and 536870904 bytes from a region of size 256 [-Werror=stringop-overread] > > 114 | #define __underlying_memcpy __builtin_memcpy > > | ^ > > ./include/linux/fortify-string.h:633:9: note: in expansion of macro ‘__underlying_memcpy’ > > 633 | __underlying_##op(p, q, __fortify_size); \ > > | ^~~~~~~~~~~~~ > > ./include/linux/fortify-string.h:678:26: note: in expansion of macro ‘__fortify_memcpy_chk’ > > 678 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ > > | ^~~~~~~~~~~~~~~~~~~~ > > ./include/linux/bitmap.h:259:17: note: in expansion of macro ‘memcpy’ > > 259 | memcpy(dst, src, len); > > | ^~~~~~ > > kernel/padata.c: In function ‘__padata_set_cpumasks’: > > kernel/padata.c:713:48: note: source object ‘pcpumask’ of size [0, 256] > > 713 | cpumask_var_t pcpumask, > > | ~~~~~~~~~~~~~~^~~~~~~~ > > > > Apparently, above errors only manifests with GCC 13.x and config option > > CONFIG_FORTIFY_SOURCE. Furthermore, if I use gcc 11.x or gcc 12.x then I > > don't encounter above errors. Prima facie, these errors appear to be false- > > positive. Brian informed me that currently some efforts are underway by > > GCC developers to emit more verbose information when GCC detects string > > overflow errors and that might help to further narrow down the root cause > > of this error. So for now, silence these errors using -Wno-stringop- > > overread gcc option while building kernel/padata.c file until we find the > > root cause. > > I'm hitting this now on Linus's tree using gcc14 on x86-64 so this isn't > just a problem with your arch. > > Let me try this patch locally and see if it helps... Yes, fixes the build for me, so either this is a real fix, or something else needs to be done for it, so I'll give a: Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> for now. thanks, greg k-h
