Re: Build/qemu test results for v4.18-rc4
On Mon, Jul 09, 2018 at 11:19:17AM -0700, Kees Cook wrote: > On Mon, Jul 9, 2018 at 11:16 AM, Christian Borntraeger > wrote: > > > > > > On 07/09/2018 08:06 PM, Kees Cook wrote: > >> On Mon, Jul 9, 2018 at 10:55 AM, Guenter Roeck wrote: > >>> s390:allmodconfig: > >>> > >>> arch/s390/kernel/als.o: In function `verify_facilities': > >>> als.c:(.init.text+0x24): undefined reference to `latent_entropy' > >>> als.c:(.init.text+0xae): undefined reference to `latent_entropy' > >>> make[3]: *** [arch/s390/boot/compressed/vmlinux] Error 1 > >>> make[2]: *** [arch/s390/boot/compressed/vmlinux] Error 2 > >>> make[1]: *** [bzImage] Error 2 > >>> > >>> This problem is only seen when using a compiler which has the relevant > >>> plugins enabled. Bisect points to commit 1658dcee3d43ed ("gcc-plugins: > >>> allow to enable GCC_PLUGINS for COMPILE_TEST") as the culprit. I don't > >>> know if a fix for v4.18 has been submitted. The s390 boot code in -next > >>> has been rearranged and the problem is no longer seen there. > >> > >> Hm, that would imply that mm/page_alloc.o wasn't visible during the > >> als.o linking? But ... if the problem is gone, I guess... good? > > > > als.o is used to detect if the kernel was compiled for a newer generation > > than the hardware that we are running on (very early). So it is compiled > > without gcov, kcov,ubsan and with a different march -in other words special. > > In linux-next we moved the als part to the decompressor which avoids all > > these kind of special handling. As this is part of a bigger patch set it > > would be non-trivial to backport that for 4.18. > > So unless we want to have it fixed for 4.18 I think we are fine. > > Okay, cool. If you want to fix it for 4.18, it should just be > something like this in the Makefile: > > CFLAGS_als.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) > Yes, I confirmed that this fixes the problem. Thanks, Guenter
Re: Build/qemu test results for v4.18-rc4
On Mon, Jul 09, 2018 at 08:16:04PM +0200, Christian Borntraeger wrote: > > > On 07/09/2018 08:06 PM, Kees Cook wrote: > > On Mon, Jul 9, 2018 at 10:55 AM, Guenter Roeck wrote: > >> s390:allmodconfig: > >> > >> arch/s390/kernel/als.o: In function `verify_facilities': > >> als.c:(.init.text+0x24): undefined reference to `latent_entropy' > >> als.c:(.init.text+0xae): undefined reference to `latent_entropy' > >> make[3]: *** [arch/s390/boot/compressed/vmlinux] Error 1 > >> make[2]: *** [arch/s390/boot/compressed/vmlinux] Error 2 > >> make[1]: *** [bzImage] Error 2 > >> > >> This problem is only seen when using a compiler which has the relevant > >> plugins enabled. Bisect points to commit 1658dcee3d43ed ("gcc-plugins: > >> allow to enable GCC_PLUGINS for COMPILE_TEST") as the culprit. I don't > >> know if a fix for v4.18 has been submitted. The s390 boot code in -next > >> has been rearranged and the problem is no longer seen there. > > > > Hm, that would imply that mm/page_alloc.o wasn't visible during the > > als.o linking? But ... if the problem is gone, I guess... good? > > als.o is used to detect if the kernel was compiled for a newer generation > than the hardware that we are running on (very early). So it is compiled > without gcov, kcov,ubsan and with a different march -in other words special. > In linux-next we moved the als part to the decompressor which avoids all > these kind of special handling. As this is part of a bigger patch set it > would be non-trivial to backport that for 4.18. > So unless we want to have it fixed for 4.18 I think we are fine. > Fine with me. Please let me know if the problem won't be fixed, and I'll disable allmodconfig test builds for s390 images in v4.18. Thanks, Guenter
Re: Build/qemu test results for v4.18-rc4
On Mon, Jul 9, 2018 at 11:16 AM, Christian Borntraeger wrote: > > > On 07/09/2018 08:06 PM, Kees Cook wrote: >> On Mon, Jul 9, 2018 at 10:55 AM, Guenter Roeck wrote: >>> s390:allmodconfig: >>> >>> arch/s390/kernel/als.o: In function `verify_facilities': >>> als.c:(.init.text+0x24): undefined reference to `latent_entropy' >>> als.c:(.init.text+0xae): undefined reference to `latent_entropy' >>> make[3]: *** [arch/s390/boot/compressed/vmlinux] Error 1 >>> make[2]: *** [arch/s390/boot/compressed/vmlinux] Error 2 >>> make[1]: *** [bzImage] Error 2 >>> >>> This problem is only seen when using a compiler which has the relevant >>> plugins enabled. Bisect points to commit 1658dcee3d43ed ("gcc-plugins: >>> allow to enable GCC_PLUGINS for COMPILE_TEST") as the culprit. I don't >>> know if a fix for v4.18 has been submitted. The s390 boot code in -next >>> has been rearranged and the problem is no longer seen there. >> >> Hm, that would imply that mm/page_alloc.o wasn't visible during the >> als.o linking? But ... if the problem is gone, I guess... good? > > als.o is used to detect if the kernel was compiled for a newer generation > than the hardware that we are running on (very early). So it is compiled > without gcov, kcov,ubsan and with a different march -in other words special. > In linux-next we moved the als part to the decompressor which avoids all > these kind of special handling. As this is part of a bigger patch set it > would be non-trivial to backport that for 4.18. > So unless we want to have it fixed for 4.18 I think we are fine. Okay, cool. If you want to fix it for 4.18, it should just be something like this in the Makefile: CFLAGS_als.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) -Kees -- Kees Cook Pixel Security
Re: Build/qemu test results for v4.18-rc4
On 07/09/2018 08:06 PM, Kees Cook wrote: > On Mon, Jul 9, 2018 at 10:55 AM, Guenter Roeck wrote: >> s390:allmodconfig: >> >> arch/s390/kernel/als.o: In function `verify_facilities': >> als.c:(.init.text+0x24): undefined reference to `latent_entropy' >> als.c:(.init.text+0xae): undefined reference to `latent_entropy' >> make[3]: *** [arch/s390/boot/compressed/vmlinux] Error 1 >> make[2]: *** [arch/s390/boot/compressed/vmlinux] Error 2 >> make[1]: *** [bzImage] Error 2 >> >> This problem is only seen when using a compiler which has the relevant >> plugins enabled. Bisect points to commit 1658dcee3d43ed ("gcc-plugins: >> allow to enable GCC_PLUGINS for COMPILE_TEST") as the culprit. I don't >> know if a fix for v4.18 has been submitted. The s390 boot code in -next >> has been rearranged and the problem is no longer seen there. > > Hm, that would imply that mm/page_alloc.o wasn't visible during the > als.o linking? But ... if the problem is gone, I guess... good? als.o is used to detect if the kernel was compiled for a newer generation than the hardware that we are running on (very early). So it is compiled without gcov, kcov,ubsan and with a different march -in other words special. In linux-next we moved the als part to the decompressor which avoids all these kind of special handling. As this is part of a bigger patch set it would be non-trivial to backport that for 4.18. So unless we want to have it fixed for 4.18 I think we are fine.
Re: Build/qemu test results for v4.18-rc4
On Mon, Jul 9, 2018 at 10:55 AM, Guenter Roeck wrote: > s390:allmodconfig: > > arch/s390/kernel/als.o: In function `verify_facilities': > als.c:(.init.text+0x24): undefined reference to `latent_entropy' > als.c:(.init.text+0xae): undefined reference to `latent_entropy' > make[3]: *** [arch/s390/boot/compressed/vmlinux] Error 1 > make[2]: *** [arch/s390/boot/compressed/vmlinux] Error 2 > make[1]: *** [bzImage] Error 2 > > This problem is only seen when using a compiler which has the relevant > plugins enabled. Bisect points to commit 1658dcee3d43ed ("gcc-plugins: > allow to enable GCC_PLUGINS for COMPILE_TEST") as the culprit. I don't > know if a fix for v4.18 has been submitted. The s390 boot code in -next > has been rearranged and the problem is no longer seen there. Hm, that would imply that mm/page_alloc.o wasn't visible during the als.o linking? But ... if the problem is gone, I guess... good? -Kees -- Kees Cook Pixel Security
Build/qemu test results for v4.18-rc4
Build results: total: 134 pass: 130 fail: 4 Failed builds: nds32:defconfig nds32:allnoconfig s390:allmodconfig sparc32:allmodconfig Qemu test results: total: 158 pass: 158 fail: 0 --- nds32:defconfig: nds32le-linux-ld: kernel/time/timekeeping.o: in function `timekeeping_init': timekeeping.c:(.init.text+0x1a8): undefined reference to `__ashldi3' nds32le-linux-ld: timekeeping.c:(.init.text+0x1ac): undefined reference to `__ashldi3' nds32le-linux-ld: timekeeping.c:(.init.text+0x1ec): undefined reference to `__lshrdi3' nds32le-linux-ld: timekeeping.c:(.init.text+0x1f0): undefined reference to `__lshrdi3' Fix is available in -next with commit 78945c357f5 ("nds32: Fix build error caused by configuration flag rename"). --- s390:allmodconfig: arch/s390/kernel/als.o: In function `verify_facilities': als.c:(.init.text+0x24): undefined reference to `latent_entropy' als.c:(.init.text+0xae): undefined reference to `latent_entropy' make[3]: *** [arch/s390/boot/compressed/vmlinux] Error 1 make[2]: *** [arch/s390/boot/compressed/vmlinux] Error 2 make[1]: *** [bzImage] Error 2 This problem is only seen when using a compiler which has the relevant plugins enabled. Bisect points to commit 1658dcee3d43ed ("gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST") as the culprit. I don't know if a fix for v4.18 has been submitted. The s390 boot code in -next has been rearranged and the problem is no longer seen there. --- sparc32:allmodconfig: include/linux/highmem.h: In function 'clear_user_highpage': include/linux/highmem.h:137:31: error: passing argument 1 of 'sparc_flush_page_to_ram' from incompatible pointer type A possible fix is available at https://patchwork.kernel.org/patch/10497941/. Guenter