Re: linux-next: build warnings after merge of the kbuild tree
Hi Masahiro, On Wed, 4 Sep 2019 15:22:09 +0900 Masahiro Yamada wrote: > > For today's linux-next, please squash the following too. > > (This is my fault, since scripts/mkuboot.sh is a bash script) > > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index 41c50f9461e5..2d72327417a9 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -374,7 +374,7 @@ UIMAGE_ENTRYADDR ?= $(UIMAGE_LOADADDR) > UIMAGE_NAME ?= 'Linux-$(KERNELRELEASE)' > > quiet_cmd_uimage = UIMAGE $@ > - cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \ > + cmd_uimage = $(BASE) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \ > -C $(UIMAGE_COMPRESSION) $(UIMAGE_OPTS-y) \ > -T $(UIMAGE_TYPE) \ > -a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \ Umm, that seems to have already been done. -- Cheers, Stephen Rothwell pgpm3T9x3eAek.pgp Description: OpenPGP digital signature
Re: linux-next: build warnings after merge of the kbuild tree
Hi Masahiro, On Wed, 4 Sep 2019 10:00:30 +0900 Masahiro Yamada wrote: > > Could you fix it up as follows? > I will squash it for tomorrow's linux-next. > > > --- a/arch/powerpc/Makefile.postlink > +++ b/arch/powerpc/Makefile.postlink > @@ -18,7 +18,7 @@ quiet_cmd_relocs_check = CHKREL $@ > ifdef CONFIG_PPC_BOOK3S_64 >cmd_relocs_check = \ > $(CONFIG_SHELL) $(srctree)/arch/powerpc/tools/relocs_check.sh > "$(OBJDUMP)" "$@" ; \ > - $(CONFIG_SHELL) > $(srctree)/arch/powerpc/tools/unrel_branch_check.sh "$(OBJDUMP)" "$@" > + $(BASH) $(srctree)/arch/powerpc/tools/unrel_branch_check.sh > "$(OBJDUMP)" "$@" > else >cmd_relocs_check = \ > $(CONFIG_SHELL) $(srctree)/arch/powerpc/tools/relocs_check.sh > "$(OBJDUMP)" "$@" I added that in linux-next today. -- Cheers, Stephen Rothwell pgpvjb5JgDueW.pgp Description: OpenPGP digital signature
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, Sep 4, 2019 at 10:00 AM Masahiro Yamada wrote: > > Hi Stephen, > > On Wed, Sep 4, 2019 at 9:13 AM Stephen Rothwell wrote: > > For today's linux-next, please squash the following too. (This is my fault, since scripts/mkuboot.sh is a bash script) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 41c50f9461e5..2d72327417a9 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -374,7 +374,7 @@ UIMAGE_ENTRYADDR ?= $(UIMAGE_LOADADDR) UIMAGE_NAME ?= 'Linux-$(KERNELRELEASE)' quiet_cmd_uimage = UIMAGE $@ - cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \ + cmd_uimage = $(BASE) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \ -C $(UIMAGE_COMPRESSION) $(UIMAGE_OPTS-y) \ -T $(UIMAGE_TYPE) \ -a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \ -- Best Regards Masahiro Yamada
Re: linux-next: build warnings after merge of the kbuild tree
Hi Stephen, On Wed, Sep 4, 2019 at 9:13 AM Stephen Rothwell wrote: > > Hi all, > > After merging the kbuild tree, today's linux-next build (powerpc > ppc64_defconfig) produced these warnings: > > > Presumably introduced by commit > > 1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension") > > and presumably arch/powerpc/tools/unrel_branch_check.sh (which has no > #! line) is a bash script. Yeah, is uses '((' and '))'. Thanks for catching this. Could you fix it up as follows? I will squash it for tomorrow's linux-next. --- a/arch/powerpc/Makefile.postlink +++ b/arch/powerpc/Makefile.postlink @@ -18,7 +18,7 @@ quiet_cmd_relocs_check = CHKREL $@ ifdef CONFIG_PPC_BOOK3S_64 cmd_relocs_check = \ $(CONFIG_SHELL) $(srctree)/arch/powerpc/tools/relocs_check.sh "$(OBJDUMP)" "$@" ; \ - $(CONFIG_SHELL) $(srctree)/arch/powerpc/tools/unrel_branch_check.sh "$(OBJDUMP)" "$@" + $(BASH) $(srctree)/arch/powerpc/tools/unrel_branch_check.sh "$(OBJDUMP)" "$@" else cmd_relocs_check = \ $(CONFIG_SHELL) $(srctree)/arch/powerpc/tools/relocs_check.sh "$(OBJDUMP)" "$@" > -- > Cheers, > Stephen Rothwell -- Best Regards Masahiro Yamada
linux-next: build warnings after merge of the kbuild tree
Hi all, After merging the kbuild tree, today's linux-next build (powerpc ppc64_defconfig) produced these warnings: Presumably introduced by commit 1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension") and presumably arch/powerpc/tools/unrel_branch_check.sh (which has no #! line) is a bash script. Yeah, is uses '((' and '))'. -- Cheers, Stephen Rothwell pgpOyYDrOvqul.pgp Description: OpenPGP digital signature
Re: linux-next: build warnings after merge of the kbuild tree
On Sat, Jun 2, 2018 at 10:39 PM, Arnd Bergmann wrote: > I ran into the same thing indepently and bisected it (which led me to > arrive at this thread). > One additional bit of information I have is that this happens with all > versions of > gcc-7 for me, but not gcc-6.3 or older. > > Another finding was the particular instance I noticed: > > fs/ext4/inode.c: In function 'ext4_inode_csum': > fs/ext4/inode.c:83:1: warning: the frame size of 1688 bytes is larger > than 500 bytes [-Wframe-larger-than=] > > comes from inlining the same function multiple times; ext4_inode_csum() > repeatedly calls ext4_chksum(), which has a struct on the stack. Apparently > this normally only takes up stack space only once, but when initializing it > to zero, each instance takes an additional two CRYPTO_MINALIGN bytes > of stack space (the size of the locally defined structure). Two more things: * I believe we still want to leave CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL depending on !COMPILE_TEST indefinitely. The reason is that it effectively turns off -Wmaybe-uninitialized warnings by initializing all structures, so we would miss those warnings in allmodconfig builds otherwise. Obviously that shouldn't stop of from fixing the excessive stack usage. * Here is the full list of instances in which a function stack usage grows beyond the warning limit with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL enabled, after several hundred randconfig builds on arm32/arm64/x86: drivers/media/dvb-core/dvb_frontend.c: In function 'dvb_frontend_handle_ioctl': drivers/media/dvb-core/dvb_frontend.c:2647:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] fs/ext4/super.c: In function 'ext4_group_desc_csum': fs/ext4/super.c:2306:1: error: the frame size of 1160 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] fs/ext4/xattr.c: In function 'ext4_xattr_block_csum': fs/ext4/xattr.c:147:1: error: the frame size of 1168 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] fs/f2fs/inode.c: In function 'f2fs_inode_chksum': fs/f2fs/inode.c:156:1: error: the frame size of 1424 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] net/bluetooth/l2cap_core.c: In function 'l2cap_recv_frame': net/bluetooth/l2cap_core.c:6976:1: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] drivers/media/i2c/soc_camera/ov9740.c: In function 'ov9740_set_res': drivers/media/i2c/soc_camera/ov9740.c:668:1: error: the frame size of 2768 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] I did not see the brcmsmac warning on my builds though, so presumably there are some others as well. Arnd
Re: linux-next: build warnings after merge of the kbuild tree
On Sat, Jun 2, 2018 at 10:39 PM, Arnd Bergmann wrote: > I ran into the same thing indepently and bisected it (which led me to > arrive at this thread). > One additional bit of information I have is that this happens with all > versions of > gcc-7 for me, but not gcc-6.3 or older. > > Another finding was the particular instance I noticed: > > fs/ext4/inode.c: In function 'ext4_inode_csum': > fs/ext4/inode.c:83:1: warning: the frame size of 1688 bytes is larger > than 500 bytes [-Wframe-larger-than=] > > comes from inlining the same function multiple times; ext4_inode_csum() > repeatedly calls ext4_chksum(), which has a struct on the stack. Apparently > this normally only takes up stack space only once, but when initializing it > to zero, each instance takes an additional two CRYPTO_MINALIGN bytes > of stack space (the size of the locally defined structure). Two more things: * I believe we still want to leave CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL depending on !COMPILE_TEST indefinitely. The reason is that it effectively turns off -Wmaybe-uninitialized warnings by initializing all structures, so we would miss those warnings in allmodconfig builds otherwise. Obviously that shouldn't stop of from fixing the excessive stack usage. * Here is the full list of instances in which a function stack usage grows beyond the warning limit with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL enabled, after several hundred randconfig builds on arm32/arm64/x86: drivers/media/dvb-core/dvb_frontend.c: In function 'dvb_frontend_handle_ioctl': drivers/media/dvb-core/dvb_frontend.c:2647:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] fs/ext4/super.c: In function 'ext4_group_desc_csum': fs/ext4/super.c:2306:1: error: the frame size of 1160 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] fs/ext4/xattr.c: In function 'ext4_xattr_block_csum': fs/ext4/xattr.c:147:1: error: the frame size of 1168 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] fs/f2fs/inode.c: In function 'f2fs_inode_chksum': fs/f2fs/inode.c:156:1: error: the frame size of 1424 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] net/bluetooth/l2cap_core.c: In function 'l2cap_recv_frame': net/bluetooth/l2cap_core.c:6976:1: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] drivers/media/i2c/soc_camera/ov9740.c: In function 'ov9740_set_res': drivers/media/i2c/soc_camera/ov9740.c:668:1: error: the frame size of 2768 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] I did not see the brcmsmac warning on my builds though, so presumably there are some others as well. Arnd
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, Jun 1, 2018 at 6:01 AM, Kees Cook wrote: > On Thu, May 31, 2018 at 6:56 PM, Masahiro Yamada > wrote: >> 2018-05-31 12:53 GMT+09:00 Kees Cook : >>> On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote: On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada > This has been triggered by the following commit: > > > commit 0e461945f3504e09b8ecf947b6398adce1287a28 > Author: Masahiro Yamada > Date: Mon May 28 18:22:07 2018 +0900 > > gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST > > > > CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled > for COMPILE_TEST, which is now enabled. > > For the moment, can you add "depends on !COMPILE_TEST" to > CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL in your tree and I'll continue > to figure out what's happening? > I ran into the same thing indepently and bisected it (which led me to arrive at this thread). One additional bit of information I have is that this happens with all versions of gcc-7 for me, but not gcc-6.3 or older. Another finding was the particular instance I noticed: fs/ext4/inode.c: In function 'ext4_inode_csum': fs/ext4/inode.c:83:1: warning: the frame size of 1688 bytes is larger than 500 bytes [-Wframe-larger-than=] comes from inlining the same function multiple times; ext4_inode_csum() repeatedly calls ext4_chksum(), which has a struct on the stack. Apparently this normally only takes up stack space only once, but when initializing it to zero, each instance takes an additional two CRYPTO_MINALIGN bytes of stack space (the size of the locally defined structure). Arnd
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, Jun 1, 2018 at 6:01 AM, Kees Cook wrote: > On Thu, May 31, 2018 at 6:56 PM, Masahiro Yamada > wrote: >> 2018-05-31 12:53 GMT+09:00 Kees Cook : >>> On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote: On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada > This has been triggered by the following commit: > > > commit 0e461945f3504e09b8ecf947b6398adce1287a28 > Author: Masahiro Yamada > Date: Mon May 28 18:22:07 2018 +0900 > > gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST > > > > CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled > for COMPILE_TEST, which is now enabled. > > For the moment, can you add "depends on !COMPILE_TEST" to > CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL in your tree and I'll continue > to figure out what's happening? > I ran into the same thing indepently and bisected it (which led me to arrive at this thread). One additional bit of information I have is that this happens with all versions of gcc-7 for me, but not gcc-6.3 or older. Another finding was the particular instance I noticed: fs/ext4/inode.c: In function 'ext4_inode_csum': fs/ext4/inode.c:83:1: warning: the frame size of 1688 bytes is larger than 500 bytes [-Wframe-larger-than=] comes from inlining the same function multiple times; ext4_inode_csum() repeatedly calls ext4_chksum(), which has a struct on the stack. Apparently this normally only takes up stack space only once, but when initializing it to zero, each instance takes an additional two CRYPTO_MINALIGN bytes of stack space (the size of the locally defined structure). Arnd
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, May 31, 2018 at 6:56 PM, Masahiro Yamada wrote: > 2018-05-31 12:53 GMT+09:00 Kees Cook : >> On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote: >>> On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada >>> wrote: Hi. (+CC Kees) 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : > Hi Masahiro, > > After merging the kbuild tree, today's linux-next build (x86_64 > allmodconfig) produced these warnings: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_rev7': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: > warning: the frame size of 3136 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_rev3': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: > warning: the frame size of 2872 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_cal_txiqlo_nphy': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: > warning: the frame size of 2432 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > > I have no idea what caused these warnings to appear ... nothing in those > functions looks too bad. This has been triggered by the following commit: commit 0e461945f3504e09b8ecf947b6398adce1287a28 Author: Masahiro Yamada Date: Mon May 28 18:22:07 2018 +0900 gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled for COMPILE_TEST, which is now enabled. For the moment, can you add "depends on !COMPILE_TEST" to CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL in your tree and I'll continue to figure out what's happening? Thanks! -Kees -- Kees Cook Pixel Security
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, May 31, 2018 at 6:56 PM, Masahiro Yamada wrote: > 2018-05-31 12:53 GMT+09:00 Kees Cook : >> On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote: >>> On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada >>> wrote: Hi. (+CC Kees) 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : > Hi Masahiro, > > After merging the kbuild tree, today's linux-next build (x86_64 > allmodconfig) produced these warnings: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_rev7': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: > warning: the frame size of 3136 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_rev3': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: > warning: the frame size of 2872 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_cal_txiqlo_nphy': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: > warning: the frame size of 2432 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > > I have no idea what caused these warnings to appear ... nothing in those > functions looks too bad. This has been triggered by the following commit: commit 0e461945f3504e09b8ecf947b6398adce1287a28 Author: Masahiro Yamada Date: Mon May 28 18:22:07 2018 +0900 gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled for COMPILE_TEST, which is now enabled. For the moment, can you add "depends on !COMPILE_TEST" to CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL in your tree and I'll continue to figure out what's happening? Thanks! -Kees -- Kees Cook Pixel Security
Re: linux-next: build warnings after merge of the kbuild tree
2018-05-31 12:53 GMT+09:00 Kees Cook : > On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote: >> On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada >> wrote: >>> Hi. >>> (+CC Kees) >>> >>> 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : Hi Masahiro, After merging the kbuild tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_rev7': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: warning: the frame size of 3136 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_rev3': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: warning: the frame size of 2872 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_cal_txiqlo_nphy': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: warning: the frame size of 2432 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ I have no idea what caused these warnings to appear ... nothing in those functions looks too bad. >>> >>> >>> This has been triggered by the following commit: >>> >>> >>> commit 0e461945f3504e09b8ecf947b6398adce1287a28 >>> Author: Masahiro Yamada >>> Date: Mon May 28 18:22:07 2018 +0900 >>> >>> gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST >>> >>> >>> >>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled >>> for COMPILE_TEST, which is now enabled. >> >> Weird -- I do build tests with plugins enabled pretty regularly. I >> hadn't seen this before. I'll see if I can figure out what the >> combination is... > > Weirdly, I only see this after merging kbuild/for-next into > next-20180530. (I don't get the warning if I just force the plugins > on.) I see this warning on Linus' tree as well if the plugins are enabled. Just remove "depends on !COMPILE_TEST", and try allmodconfig. masahiro@grover:~/ref/linux$ git show --pretty=short commit 0512e0134582ef85dee77d51aae77dcd1edec495 Merge: dd52cb8 829bc787 Author: Linus Torvalds Merge tag 'xfs-4.17-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux masahiro@grover:~/ref/linux$ git diff diff --git a/arch/Kconfig b/arch/Kconfig index 75dd23a..7d44cfe 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -410,7 +410,6 @@ config HAVE_GCC_PLUGINS menuconfig GCC_PLUGINS bool "GCC plugins" depends on HAVE_GCC_PLUGINS - depends on !COMPILE_TEST help GCC plugins are loadable modules that provide extra features to the compiler. They are useful for runtime instrumentation and static analysis. masahiro@grover:~/ref/linux$ make allmodconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o YACCscripts/kconfig/zconf.tab.c LEX scripts/kconfig/zconf.lex.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --allmodconfig Kconfig # # configuration written to .config # masahiro@grover:~/ref/linux$ make drivers/net/wireless/broadcom/brcm80211/brcmsmac/ scripts/kconfig/conf --syncconfig Kconfig SYSTBL arch/x86/include/generated/asm/syscalls_32.h SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h SYSTBL arch/x86/include/generated/asm/syscalls_64.h HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h HOSTCC scripts/basic/bin2c HOSTCC arch/x86/tools/relocs_32.o HOSTCC arch/x86/tools/relocs_64.o HOSTCC arch/x86/tools/relocs_common.o HOSTLD arch/x86/tools/relocs CHK include/config/kernel.release UPD include/config/kernel.release WRAParch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAParch/x86/include/generated/uapi/asm/poll.h WRAParch/x86/include/generated/asm/dma-contiguous.h WRAParch/x86/include/generated/asm/early_ioremap.h WRAParch/x86/include/generated/asm/mcs_spinlock.h WRAParch/x86/include/generated/asm/mm-arch-hooks.h CHK include/generated/uapi/linux/version.h UPD include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC arch/x86/purgatory/purgatory.o AS arch/x86/purgatory/stack.o AS arch/x86/purgatory/setup-x86_64.o CC arch/x86/purgatory/sha256.o AS arch/x86/purgatory/entry64.o CC arch/x86/purgatory/string.o LD arch/x86/purgatory/purgatory.ro BIN2C arch/x86/purgatory/kexec-purgatory.c HOSTCXX
Re: linux-next: build warnings after merge of the kbuild tree
2018-05-31 12:53 GMT+09:00 Kees Cook : > On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote: >> On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada >> wrote: >>> Hi. >>> (+CC Kees) >>> >>> 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : Hi Masahiro, After merging the kbuild tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_rev7': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: warning: the frame size of 3136 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_rev3': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: warning: the frame size of 2872 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_cal_txiqlo_nphy': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: warning: the frame size of 2432 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ I have no idea what caused these warnings to appear ... nothing in those functions looks too bad. >>> >>> >>> This has been triggered by the following commit: >>> >>> >>> commit 0e461945f3504e09b8ecf947b6398adce1287a28 >>> Author: Masahiro Yamada >>> Date: Mon May 28 18:22:07 2018 +0900 >>> >>> gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST >>> >>> >>> >>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled >>> for COMPILE_TEST, which is now enabled. >> >> Weird -- I do build tests with plugins enabled pretty regularly. I >> hadn't seen this before. I'll see if I can figure out what the >> combination is... > > Weirdly, I only see this after merging kbuild/for-next into > next-20180530. (I don't get the warning if I just force the plugins > on.) I see this warning on Linus' tree as well if the plugins are enabled. Just remove "depends on !COMPILE_TEST", and try allmodconfig. masahiro@grover:~/ref/linux$ git show --pretty=short commit 0512e0134582ef85dee77d51aae77dcd1edec495 Merge: dd52cb8 829bc787 Author: Linus Torvalds Merge tag 'xfs-4.17-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux masahiro@grover:~/ref/linux$ git diff diff --git a/arch/Kconfig b/arch/Kconfig index 75dd23a..7d44cfe 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -410,7 +410,6 @@ config HAVE_GCC_PLUGINS menuconfig GCC_PLUGINS bool "GCC plugins" depends on HAVE_GCC_PLUGINS - depends on !COMPILE_TEST help GCC plugins are loadable modules that provide extra features to the compiler. They are useful for runtime instrumentation and static analysis. masahiro@grover:~/ref/linux$ make allmodconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o YACCscripts/kconfig/zconf.tab.c LEX scripts/kconfig/zconf.lex.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --allmodconfig Kconfig # # configuration written to .config # masahiro@grover:~/ref/linux$ make drivers/net/wireless/broadcom/brcm80211/brcmsmac/ scripts/kconfig/conf --syncconfig Kconfig SYSTBL arch/x86/include/generated/asm/syscalls_32.h SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h SYSTBL arch/x86/include/generated/asm/syscalls_64.h HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h HOSTCC scripts/basic/bin2c HOSTCC arch/x86/tools/relocs_32.o HOSTCC arch/x86/tools/relocs_64.o HOSTCC arch/x86/tools/relocs_common.o HOSTLD arch/x86/tools/relocs CHK include/config/kernel.release UPD include/config/kernel.release WRAParch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAParch/x86/include/generated/uapi/asm/poll.h WRAParch/x86/include/generated/asm/dma-contiguous.h WRAParch/x86/include/generated/asm/early_ioremap.h WRAParch/x86/include/generated/asm/mcs_spinlock.h WRAParch/x86/include/generated/asm/mm-arch-hooks.h CHK include/generated/uapi/linux/version.h UPD include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC arch/x86/purgatory/purgatory.o AS arch/x86/purgatory/stack.o AS arch/x86/purgatory/setup-x86_64.o CC arch/x86/purgatory/sha256.o AS arch/x86/purgatory/entry64.o CC arch/x86/purgatory/string.o LD arch/x86/purgatory/purgatory.ro BIN2C arch/x86/purgatory/kexec-purgatory.c HOSTCXX
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote: > On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada > wrote: >> Hi. >> (+CC Kees) >> >> 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : >>> Hi Masahiro, >>> >>> After merging the kbuild tree, today's linux-next build (x86_64 >>> allmodconfig) produced these warnings: >>> >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >>> 'wlc_phy_workarounds_nphy_rev7': >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: >>> warning: the frame size of 3136 bytes is larger than 2048 bytes >>> [-Wframe-larger-than=] >>> } >>> ^ >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >>> 'wlc_phy_workarounds_nphy_rev3': >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: >>> warning: the frame size of 2872 bytes is larger than 2048 bytes >>> [-Wframe-larger-than=] >>> } >>> ^ >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >>> 'wlc_phy_cal_txiqlo_nphy': >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: >>> warning: the frame size of 2432 bytes is larger than 2048 bytes >>> [-Wframe-larger-than=] >>> } >>> ^ >>> >>> I have no idea what caused these warnings to appear ... nothing in those >>> functions looks too bad. >> >> >> This has been triggered by the following commit: >> >> >> commit 0e461945f3504e09b8ecf947b6398adce1287a28 >> Author: Masahiro Yamada >> Date: Mon May 28 18:22:07 2018 +0900 >> >> gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST >> >> >> >> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled >> for COMPILE_TEST, which is now enabled. > > Weird -- I do build tests with plugins enabled pretty regularly. I > hadn't seen this before. I'll see if I can figure out what the > combination is... Weirdly, I only see this after merging kbuild/for-next into next-20180530. (I don't get the warning if I just force the plugins on.) Regardless, I can confirm that CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL trips it. I'll investigate more tomorrow... -Kees -- Kees Cook Pixel Security
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote: > On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada > wrote: >> Hi. >> (+CC Kees) >> >> 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : >>> Hi Masahiro, >>> >>> After merging the kbuild tree, today's linux-next build (x86_64 >>> allmodconfig) produced these warnings: >>> >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >>> 'wlc_phy_workarounds_nphy_rev7': >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: >>> warning: the frame size of 3136 bytes is larger than 2048 bytes >>> [-Wframe-larger-than=] >>> } >>> ^ >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >>> 'wlc_phy_workarounds_nphy_rev3': >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: >>> warning: the frame size of 2872 bytes is larger than 2048 bytes >>> [-Wframe-larger-than=] >>> } >>> ^ >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >>> 'wlc_phy_cal_txiqlo_nphy': >>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: >>> warning: the frame size of 2432 bytes is larger than 2048 bytes >>> [-Wframe-larger-than=] >>> } >>> ^ >>> >>> I have no idea what caused these warnings to appear ... nothing in those >>> functions looks too bad. >> >> >> This has been triggered by the following commit: >> >> >> commit 0e461945f3504e09b8ecf947b6398adce1287a28 >> Author: Masahiro Yamada >> Date: Mon May 28 18:22:07 2018 +0900 >> >> gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST >> >> >> >> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled >> for COMPILE_TEST, which is now enabled. > > Weird -- I do build tests with plugins enabled pretty regularly. I > hadn't seen this before. I'll see if I can figure out what the > combination is... Weirdly, I only see this after merging kbuild/for-next into next-20180530. (I don't get the warning if I just force the plugins on.) Regardless, I can confirm that CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL trips it. I'll investigate more tomorrow... -Kees -- Kees Cook Pixel Security
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada wrote: > Hi. > (+CC Kees) > > 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : >> Hi Masahiro, >> >> After merging the kbuild tree, today's linux-next build (x86_64 >> allmodconfig) produced these warnings: >> >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >> 'wlc_phy_workarounds_nphy_rev7': >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: >> warning: the frame size of 3136 bytes is larger than 2048 bytes >> [-Wframe-larger-than=] >> } >> ^ >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >> 'wlc_phy_workarounds_nphy_rev3': >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: >> warning: the frame size of 2872 bytes is larger than 2048 bytes >> [-Wframe-larger-than=] >> } >> ^ >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >> 'wlc_phy_cal_txiqlo_nphy': >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: >> warning: the frame size of 2432 bytes is larger than 2048 bytes >> [-Wframe-larger-than=] >> } >> ^ >> >> I have no idea what caused these warnings to appear ... nothing in those >> functions looks too bad. > > > This has been triggered by the following commit: > > > commit 0e461945f3504e09b8ecf947b6398adce1287a28 > Author: Masahiro Yamada > Date: Mon May 28 18:22:07 2018 +0900 > > gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST > > > > CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled > for COMPILE_TEST, which is now enabled. Weird -- I do build tests with plugins enabled pretty regularly. I hadn't seen this before. I'll see if I can figure out what the combination is... > COMPILE_TEST now enables GCC plugin for wider test coverage, > this is a good thing in general. Yes indeed! -Kees -- Kees Cook Pixel Security
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada wrote: > Hi. > (+CC Kees) > > 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : >> Hi Masahiro, >> >> After merging the kbuild tree, today's linux-next build (x86_64 >> allmodconfig) produced these warnings: >> >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >> 'wlc_phy_workarounds_nphy_rev7': >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: >> warning: the frame size of 3136 bytes is larger than 2048 bytes >> [-Wframe-larger-than=] >> } >> ^ >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >> 'wlc_phy_workarounds_nphy_rev3': >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: >> warning: the frame size of 2872 bytes is larger than 2048 bytes >> [-Wframe-larger-than=] >> } >> ^ >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function >> 'wlc_phy_cal_txiqlo_nphy': >> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: >> warning: the frame size of 2432 bytes is larger than 2048 bytes >> [-Wframe-larger-than=] >> } >> ^ >> >> I have no idea what caused these warnings to appear ... nothing in those >> functions looks too bad. > > > This has been triggered by the following commit: > > > commit 0e461945f3504e09b8ecf947b6398adce1287a28 > Author: Masahiro Yamada > Date: Mon May 28 18:22:07 2018 +0900 > > gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST > > > > CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled > for COMPILE_TEST, which is now enabled. Weird -- I do build tests with plugins enabled pretty regularly. I hadn't seen this before. I'll see if I can figure out what the combination is... > COMPILE_TEST now enables GCC plugin for wider test coverage, > this is a good thing in general. Yes indeed! -Kees -- Kees Cook Pixel Security
Re: linux-next: build warnings after merge of the kbuild tree
Hi. (+CC Kees) 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : > Hi Masahiro, > > After merging the kbuild tree, today's linux-next build (x86_64 > allmodconfig) produced these warnings: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_rev7': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: > warning: the frame size of 3136 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_rev3': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: > warning: the frame size of 2872 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_cal_txiqlo_nphy': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: > warning: the frame size of 2432 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > > I have no idea what caused these warnings to appear ... nothing in those > functions looks too bad. This has been triggered by the following commit: commit 0e461945f3504e09b8ecf947b6398adce1287a28 Author: Masahiro Yamada Date: Mon May 28 18:22:07 2018 +0900 gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled for COMPILE_TEST, which is now enabled. COMPILE_TEST now enables GCC plugin for wider test coverage, this is a good thing in general. -- Best Regards Masahiro Yamada
Re: linux-next: build warnings after merge of the kbuild tree
Hi. (+CC Kees) 2018-05-31 7:40 GMT+09:00 Stephen Rothwell : > Hi Masahiro, > > After merging the kbuild tree, today's linux-next build (x86_64 > allmodconfig) produced these warnings: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_rev7': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: > warning: the frame size of 3136 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_rev3': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: > warning: the frame size of 2872 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_cal_txiqlo_nphy': > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: > warning: the frame size of 2432 bytes is larger than 2048 bytes > [-Wframe-larger-than=] > } > ^ > > I have no idea what caused these warnings to appear ... nothing in those > functions looks too bad. This has been triggered by the following commit: commit 0e461945f3504e09b8ecf947b6398adce1287a28 Author: Masahiro Yamada Date: Mon May 28 18:22:07 2018 +0900 gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled for COMPILE_TEST, which is now enabled. COMPILE_TEST now enables GCC plugin for wider test coverage, this is a good thing in general. -- Best Regards Masahiro Yamada
linux-next: build warnings after merge of the kbuild tree
Hi Masahiro, After merging the kbuild tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_rev7': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: warning: the frame size of 3136 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_rev3': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: warning: the frame size of 2872 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_cal_txiqlo_nphy': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: warning: the frame size of 2432 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ I have no idea what caused these warnings to appear ... nothing in those functions looks too bad. -- Cheers, Stephen Rothwell pgpdnHxEuOF1g.pgp Description: OpenPGP digital signature
linux-next: build warnings after merge of the kbuild tree
Hi Masahiro, After merging the kbuild tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_rev7': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: warning: the frame size of 3136 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_rev3': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: warning: the frame size of 2872 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_cal_txiqlo_nphy': drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26033:1: warning: the frame size of 2432 bytes is larger than 2048 bytes [-Wframe-larger-than=] } ^ I have no idea what caused these warnings to appear ... nothing in those functions looks too bad. -- Cheers, Stephen Rothwell pgpdnHxEuOF1g.pgp Description: OpenPGP digital signature
linux-next: build warnings after merge of the kbuild tree
Hi all, After merging the kbuild tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: WARNING: drivers/atm/fore_200e.o(.rodata+0x2258): Section mismatch in reference from the variable fore200e_bus to the function .init.text:fore200e_pca_prom_read() The variable fore200e_bus references the function __init fore200e_pca_prom_read() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x560): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x568): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x570): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x578): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x580): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x588): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3700): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3708): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3710): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3718): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3720): Section mismatch in reference from
linux-next: build warnings after merge of the kbuild tree
Hi all, After merging the kbuild tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: WARNING: drivers/atm/fore_200e.o(.rodata+0x2258): Section mismatch in reference from the variable fore200e_bus to the function .init.text:fore200e_pca_prom_read() The variable fore200e_bus references the function __init fore200e_pca_prom_read() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x560): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x568): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x570): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x578): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x580): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/auxdisplay/panel.o(.rodata+0x588): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3700): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3708): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3710): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3718): Section mismatch in reference from the (unknown reference) (unknown) to the (unknown reference) .init.text:(unknown) The variable (unknown) references the (unknown reference) __init (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/edac/amd64_edac_mod.o(.rodata+0x3720): Section mismatch in reference from
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, Aug 26, 2016 at 01:58:03PM +1000, Nicholas Piggin wrote: > On Mon, 22 Aug 2016 20:47:58 +1000 > Nicholas Pigginwrote: > > > On Fri, 19 Aug 2016 20:44:55 +1000 > > Nicholas Piggin wrote: > > > > > On Fri, 19 Aug 2016 10:37:00 +0200 > > > Michal Marek wrote: > > > > > > > On 2016-08-19 07:09, Stephen Rothwell wrote: > > > > [snip] > > > > > > > > > > > > I may be missing something, but genksyms generates the crc's off the > > > > > preprocessed C source code and we don't have any for the asm files > > > > > ... > > > > > > > > Of course you are right. Which means that we are losing type information > > > > for these exports for CONFIG_MODVERSIONS purposes. I guess it's > > > > acceptable, since the asm functions are pretty basic and their > > > > signatures do not change. > > > > > > I don't completely agree. It would be nice to have the functionality > > > still there. > > > > > > What happens if you just run cmd_modversions on the as rule? It relies on > > > !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as. > > > It would require the header be included in the .S file and be protected > > > for > > > asm builds. > > > > > > This seems like it *could* be made to work, but there's a few problems. > > > > - .h files are not made for C consumption. Matter of manually adding the > > ifdef guards, which isn't terrible. > > > > - .S files do not all include their .h where the C declaration is. Also > > will cause some churn but doable and maybe not completely unreasonable. > > > > - genksyms parser barfs when it hits the assembly of the .S file. Best > > way to fix that seems just send the #include and EXPORT_SYMBOL lines > > from the .S to the preprocessor. That's a bit of a rabbit hole too, with > > some .S files being included, etc. > > > > I'm not sure what to do here. If nobody cares and we lose CRCs for .S > > exports, then okay we can whitelist those relocs easily. If we don't want > > to lose the functionality, the above might work but it's a bit intrusive > > an is going to require another cycle of prep patches to go through arch > > code first. > > > > Or suggestions for alternative approach? > > Here is a quick patch that I think should catch missing CRCs in > architecture independent way. If we merge something like this, we > can whitelist the symbols in arch/powerpc so people get steered to > the right place. > > Powerpc seems to be the only one really catching this, and it's > only as a side effect of a test run for CONFIG_RELOCATABLE kernels, > which means version failures probably slipped through other archs. > > I'll clean it up, do some more testing, and submit it unless > anybody dislikes it or has a better way to do it. > > Thanks, > Nick > > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > index 4b8ffd3..1efc454 100644 > --- a/scripts/mod/modpost.c > +++ b/scripts/mod/modpost.c > @@ -609,6 +609,7 @@ static void handle_modversions(struct module *mod, struct > elf_info *info, > { > unsigned int crc; > enum export export; > + int is_crc = 0; should that not be a bool here ? > > if ((!is_vmlinux(mod->name) || mod->is_dot_o) && > strncmp(symname, "__ksymtab", 9) == 0) > @@ -618,6 +619,7 @@ static void handle_modversions(struct module *mod, struct > elf_info *info, > > /* CRC'd symbol */ > if (strncmp(symname, CRC_PFX, strlen(CRC_PFX)) == 0) { > + is_crc = 1; is_crc = true; > crc = (unsigned int) sym->st_value; > sym_update_crc(symname + strlen(CRC_PFX), mod, crc, > export); thx! hofrat
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, Aug 26, 2016 at 01:58:03PM +1000, Nicholas Piggin wrote: > On Mon, 22 Aug 2016 20:47:58 +1000 > Nicholas Piggin wrote: > > > On Fri, 19 Aug 2016 20:44:55 +1000 > > Nicholas Piggin wrote: > > > > > On Fri, 19 Aug 2016 10:37:00 +0200 > > > Michal Marek wrote: > > > > > > > On 2016-08-19 07:09, Stephen Rothwell wrote: > > > > [snip] > > > > > > > > > > > > I may be missing something, but genksyms generates the crc's off the > > > > > preprocessed C source code and we don't have any for the asm files > > > > > ... > > > > > > > > Of course you are right. Which means that we are losing type information > > > > for these exports for CONFIG_MODVERSIONS purposes. I guess it's > > > > acceptable, since the asm functions are pretty basic and their > > > > signatures do not change. > > > > > > I don't completely agree. It would be nice to have the functionality > > > still there. > > > > > > What happens if you just run cmd_modversions on the as rule? It relies on > > > !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as. > > > It would require the header be included in the .S file and be protected > > > for > > > asm builds. > > > > > > This seems like it *could* be made to work, but there's a few problems. > > > > - .h files are not made for C consumption. Matter of manually adding the > > ifdef guards, which isn't terrible. > > > > - .S files do not all include their .h where the C declaration is. Also > > will cause some churn but doable and maybe not completely unreasonable. > > > > - genksyms parser barfs when it hits the assembly of the .S file. Best > > way to fix that seems just send the #include and EXPORT_SYMBOL lines > > from the .S to the preprocessor. That's a bit of a rabbit hole too, with > > some .S files being included, etc. > > > > I'm not sure what to do here. If nobody cares and we lose CRCs for .S > > exports, then okay we can whitelist those relocs easily. If we don't want > > to lose the functionality, the above might work but it's a bit intrusive > > an is going to require another cycle of prep patches to go through arch > > code first. > > > > Or suggestions for alternative approach? > > Here is a quick patch that I think should catch missing CRCs in > architecture independent way. If we merge something like this, we > can whitelist the symbols in arch/powerpc so people get steered to > the right place. > > Powerpc seems to be the only one really catching this, and it's > only as a side effect of a test run for CONFIG_RELOCATABLE kernels, > which means version failures probably slipped through other archs. > > I'll clean it up, do some more testing, and submit it unless > anybody dislikes it or has a better way to do it. > > Thanks, > Nick > > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > index 4b8ffd3..1efc454 100644 > --- a/scripts/mod/modpost.c > +++ b/scripts/mod/modpost.c > @@ -609,6 +609,7 @@ static void handle_modversions(struct module *mod, struct > elf_info *info, > { > unsigned int crc; > enum export export; > + int is_crc = 0; should that not be a bool here ? > > if ((!is_vmlinux(mod->name) || mod->is_dot_o) && > strncmp(symname, "__ksymtab", 9) == 0) > @@ -618,6 +619,7 @@ static void handle_modversions(struct module *mod, struct > elf_info *info, > > /* CRC'd symbol */ > if (strncmp(symname, CRC_PFX, strlen(CRC_PFX)) == 0) { > + is_crc = 1; is_crc = true; > crc = (unsigned int) sym->st_value; > sym_update_crc(symname + strlen(CRC_PFX), mod, crc, > export); thx! hofrat
Re: linux-next: build warnings after merge of the kbuild tree
On Mon, 22 Aug 2016 20:47:58 +1000 Nicholas Pigginwrote: > On Fri, 19 Aug 2016 20:44:55 +1000 > Nicholas Piggin wrote: > > > On Fri, 19 Aug 2016 10:37:00 +0200 > > Michal Marek wrote: > > > > > On 2016-08-19 07:09, Stephen Rothwell wrote: > > [snip] > > > > > > > > > I may be missing something, but genksyms generates the crc's off the > > > > preprocessed C source code and we don't have any for the asm files ... > > > > > > > > > > Of course you are right. Which means that we are losing type information > > > for these exports for CONFIG_MODVERSIONS purposes. I guess it's > > > acceptable, since the asm functions are pretty basic and their > > > signatures do not change. > > > > I don't completely agree. It would be nice to have the functionality > > still there. > > > > What happens if you just run cmd_modversions on the as rule? It relies on > > !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as. > > It would require the header be included in the .S file and be protected for > > asm builds. > > > This seems like it *could* be made to work, but there's a few problems. > > - .h files are not made for C consumption. Matter of manually adding the > ifdef guards, which isn't terrible. > > - .S files do not all include their .h where the C declaration is. Also > will cause some churn but doable and maybe not completely unreasonable. > > - genksyms parser barfs when it hits the assembly of the .S file. Best > way to fix that seems just send the #include and EXPORT_SYMBOL lines > from the .S to the preprocessor. That's a bit of a rabbit hole too, with > some .S files being included, etc. > > I'm not sure what to do here. If nobody cares and we lose CRCs for .S > exports, then okay we can whitelist those relocs easily. If we don't want > to lose the functionality, the above might work but it's a bit intrusive > an is going to require another cycle of prep patches to go through arch > code first. > > Or suggestions for alternative approach? Here is a quick patch that I think should catch missing CRCs in architecture independent way. If we merge something like this, we can whitelist the symbols in arch/powerpc so people get steered to the right place. Powerpc seems to be the only one really catching this, and it's only as a side effect of a test run for CONFIG_RELOCATABLE kernels, which means version failures probably slipped through other archs. I'll clean it up, do some more testing, and submit it unless anybody dislikes it or has a better way to do it. Thanks, Nick diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 4b8ffd3..1efc454 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -609,6 +609,7 @@ static void handle_modversions(struct module *mod, struct elf_info *info, { unsigned int crc; enum export export; + int is_crc = 0; if ((!is_vmlinux(mod->name) || mod->is_dot_o) && strncmp(symname, "__ksymtab", 9) == 0) @@ -618,6 +619,7 @@ static void handle_modversions(struct module *mod, struct elf_info *info, /* CRC'd symbol */ if (strncmp(symname, CRC_PFX, strlen(CRC_PFX)) == 0) { + is_crc = 1; crc = (unsigned int) sym->st_value; sym_update_crc(symname + strlen(CRC_PFX), mod, crc, export); @@ -663,6 +665,10 @@ static void handle_modversions(struct module *mod, struct elf_info *info, else symname++; #endif + if (is_crc && !mod->is_dot_o) { + const char *e = is_vmlinux(mod->name) ?"":".ko"; + warn("EXPORT symbol \"%s\" [%s%s] version generation failed, symbol will not be versioned.\n", symname + strlen(CRC_PFX), mod->name, e); + } mod->unres = alloc_symbol(symname, ELF_ST_BIND(sym->st_info) == STB_WEAK, mod->unres);
Re: linux-next: build warnings after merge of the kbuild tree
On Mon, 22 Aug 2016 20:47:58 +1000 Nicholas Piggin wrote: > On Fri, 19 Aug 2016 20:44:55 +1000 > Nicholas Piggin wrote: > > > On Fri, 19 Aug 2016 10:37:00 +0200 > > Michal Marek wrote: > > > > > On 2016-08-19 07:09, Stephen Rothwell wrote: > > [snip] > > > > > > > > > I may be missing something, but genksyms generates the crc's off the > > > > preprocessed C source code and we don't have any for the asm files ... > > > > > > > > > > Of course you are right. Which means that we are losing type information > > > for these exports for CONFIG_MODVERSIONS purposes. I guess it's > > > acceptable, since the asm functions are pretty basic and their > > > signatures do not change. > > > > I don't completely agree. It would be nice to have the functionality > > still there. > > > > What happens if you just run cmd_modversions on the as rule? It relies on > > !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as. > > It would require the header be included in the .S file and be protected for > > asm builds. > > > This seems like it *could* be made to work, but there's a few problems. > > - .h files are not made for C consumption. Matter of manually adding the > ifdef guards, which isn't terrible. > > - .S files do not all include their .h where the C declaration is. Also > will cause some churn but doable and maybe not completely unreasonable. > > - genksyms parser barfs when it hits the assembly of the .S file. Best > way to fix that seems just send the #include and EXPORT_SYMBOL lines > from the .S to the preprocessor. That's a bit of a rabbit hole too, with > some .S files being included, etc. > > I'm not sure what to do here. If nobody cares and we lose CRCs for .S > exports, then okay we can whitelist those relocs easily. If we don't want > to lose the functionality, the above might work but it's a bit intrusive > an is going to require another cycle of prep patches to go through arch > code first. > > Or suggestions for alternative approach? Here is a quick patch that I think should catch missing CRCs in architecture independent way. If we merge something like this, we can whitelist the symbols in arch/powerpc so people get steered to the right place. Powerpc seems to be the only one really catching this, and it's only as a side effect of a test run for CONFIG_RELOCATABLE kernels, which means version failures probably slipped through other archs. I'll clean it up, do some more testing, and submit it unless anybody dislikes it or has a better way to do it. Thanks, Nick diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 4b8ffd3..1efc454 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -609,6 +609,7 @@ static void handle_modversions(struct module *mod, struct elf_info *info, { unsigned int crc; enum export export; + int is_crc = 0; if ((!is_vmlinux(mod->name) || mod->is_dot_o) && strncmp(symname, "__ksymtab", 9) == 0) @@ -618,6 +619,7 @@ static void handle_modversions(struct module *mod, struct elf_info *info, /* CRC'd symbol */ if (strncmp(symname, CRC_PFX, strlen(CRC_PFX)) == 0) { + is_crc = 1; crc = (unsigned int) sym->st_value; sym_update_crc(symname + strlen(CRC_PFX), mod, crc, export); @@ -663,6 +665,10 @@ static void handle_modversions(struct module *mod, struct elf_info *info, else symname++; #endif + if (is_crc && !mod->is_dot_o) { + const char *e = is_vmlinux(mod->name) ?"":".ko"; + warn("EXPORT symbol \"%s\" [%s%s] version generation failed, symbol will not be versioned.\n", symname + strlen(CRC_PFX), mod->name, e); + } mod->unres = alloc_symbol(symname, ELF_ST_BIND(sym->st_info) == STB_WEAK, mod->unres);
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, 19 Aug 2016 20:44:55 +1000 Nicholas Pigginwrote: > On Fri, 19 Aug 2016 10:37:00 +0200 > Michal Marek wrote: > > > On 2016-08-19 07:09, Stephen Rothwell wrote: [snip] > > > > > > I may be missing something, but genksyms generates the crc's off the > > > preprocessed C source code and we don't have any for the asm files ... > > > > Of course you are right. Which means that we are losing type information > > for these exports for CONFIG_MODVERSIONS purposes. I guess it's > > acceptable, since the asm functions are pretty basic and their > > signatures do not change. > > I don't completely agree. It would be nice to have the functionality > still there. > > What happens if you just run cmd_modversions on the as rule? It relies on > !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as. > It would require the header be included in the .S file and be protected for > asm builds. This seems like it *could* be made to work, but there's a few problems. - .h files are not made for C consumption. Matter of manually adding the ifdef guards, which isn't terrible. - .S files do not all include their .h where the C declaration is. Also will cause some churn but doable and maybe not completely unreasonable. - genksyms parser barfs when it hits the assembly of the .S file. Best way to fix that seems just send the #include and EXPORT_SYMBOL lines from the .S to the preprocessor. That's a bit of a rabbit hole too, with some .S files being included, etc. I'm not sure what to do here. If nobody cares and we lose CRCs for .S exports, then okay we can whitelist those relocs easily. If we don't want to lose the functionality, the above might work but it's a bit intrusive an is going to require another cycle of prep patches to go through arch code first. Or suggestions for alternative approach? Thanks, Nick
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, 19 Aug 2016 20:44:55 +1000 Nicholas Piggin wrote: > On Fri, 19 Aug 2016 10:37:00 +0200 > Michal Marek wrote: > > > On 2016-08-19 07:09, Stephen Rothwell wrote: [snip] > > > > > > I may be missing something, but genksyms generates the crc's off the > > > preprocessed C source code and we don't have any for the asm files ... > > > > Of course you are right. Which means that we are losing type information > > for these exports for CONFIG_MODVERSIONS purposes. I guess it's > > acceptable, since the asm functions are pretty basic and their > > signatures do not change. > > I don't completely agree. It would be nice to have the functionality > still there. > > What happens if you just run cmd_modversions on the as rule? It relies on > !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as. > It would require the header be included in the .S file and be protected for > asm builds. This seems like it *could* be made to work, but there's a few problems. - .h files are not made for C consumption. Matter of manually adding the ifdef guards, which isn't terrible. - .S files do not all include their .h where the C declaration is. Also will cause some churn but doable and maybe not completely unreasonable. - genksyms parser barfs when it hits the assembly of the .S file. Best way to fix that seems just send the #include and EXPORT_SYMBOL lines from the .S to the preprocessor. That's a bit of a rabbit hole too, with some .S files being included, etc. I'm not sure what to do here. If nobody cares and we lose CRCs for .S exports, then okay we can whitelist those relocs easily. If we don't want to lose the functionality, the above might work but it's a bit intrusive an is going to require another cycle of prep patches to go through arch code first. Or suggestions for alternative approach? Thanks, Nick
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, 19 Aug 2016 10:37:00 +0200 Michal Marekwrote: > On 2016-08-19 07:09, Stephen Rothwell wrote: > > Hi Nick, > > > > On Fri, 19 Aug 2016 13:38:54 +1000 Stephen Rothwell > > wrote: > >> > >> On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin > >> wrote: > >>> > >>> On Wed, 17 Aug 2016 14:59:59 +0200 > >>> Michal Marek wrote: > >>> > On 2016-08-17 03:44, Stephen Rothwell wrote: > > > > After merging the kbuild tree, today's linux-next build (powerpc > > ppc64_defconfig) produced these warnings: > > > > WARNING: 25 bad relocations > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > [...] > > Introduced by commit > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > I have reverted that commit for today. > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > ] > > FWIW, I see these warnings as well. Any help from ppc developers is > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > symbols (their CRCs actually)? > >>> > >>> The dangling relocation is a side effect of linker unable to resolve the > >>> reference to the undefined weak symbols. So the real question is, why has > >>> genksyms not overridden these symbols with their CRC values? > >>> > >>> This may not even be powerpc specific, but I'll poke at it a bit more > >>> when I get a chance. > >> > >> Not sure if this is relevant, but with the commit reverted, the > >> __crc___... symbols are absolute. > >> > >> f55b3b3d A __crc___arch_hweight16 > > > > Ignore that :-) > > > > I just had a look at a x86_64 allmodconfig result and it looks like the > > weak symbols are not resolved their either ... > > > > I may be missing something, but genksyms generates the crc's off the > > preprocessed C source code and we don't have any for the asm files ... > > Of course you are right. Which means that we are losing type information > for these exports for CONFIG_MODVERSIONS purposes. I guess it's > acceptable, since the asm functions are pretty basic and their > signatures do not change. I don't completely agree. It would be nice to have the functionality still there. What happens if you just run cmd_modversions on the as rule? It relies on !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as. It would require the header be included in the .S file and be protected for asm builds. Stephen wasn't a fan of suck a hack and I can't say I blame him. Another possibility I suppose is an EXPORT_SYMBOL_ASM() variant that takes string containing C function declaration and just inserts it as an assembler comment somewhere that genksysms can find. Thanks, Nick
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, 19 Aug 2016 10:37:00 +0200 Michal Marek wrote: > On 2016-08-19 07:09, Stephen Rothwell wrote: > > Hi Nick, > > > > On Fri, 19 Aug 2016 13:38:54 +1000 Stephen Rothwell > > wrote: > >> > >> On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin > >> wrote: > >>> > >>> On Wed, 17 Aug 2016 14:59:59 +0200 > >>> Michal Marek wrote: > >>> > On 2016-08-17 03:44, Stephen Rothwell wrote: > > > > After merging the kbuild tree, today's linux-next build (powerpc > > ppc64_defconfig) produced these warnings: > > > > WARNING: 25 bad relocations > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > [...] > > Introduced by commit > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > I have reverted that commit for today. > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > ] > > FWIW, I see these warnings as well. Any help from ppc developers is > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > symbols (their CRCs actually)? > >>> > >>> The dangling relocation is a side effect of linker unable to resolve the > >>> reference to the undefined weak symbols. So the real question is, why has > >>> genksyms not overridden these symbols with their CRC values? > >>> > >>> This may not even be powerpc specific, but I'll poke at it a bit more > >>> when I get a chance. > >> > >> Not sure if this is relevant, but with the commit reverted, the > >> __crc___... symbols are absolute. > >> > >> f55b3b3d A __crc___arch_hweight16 > > > > Ignore that :-) > > > > I just had a look at a x86_64 allmodconfig result and it looks like the > > weak symbols are not resolved their either ... > > > > I may be missing something, but genksyms generates the crc's off the > > preprocessed C source code and we don't have any for the asm files ... > > Of course you are right. Which means that we are losing type information > for these exports for CONFIG_MODVERSIONS purposes. I guess it's > acceptable, since the asm functions are pretty basic and their > signatures do not change. I don't completely agree. It would be nice to have the functionality still there. What happens if you just run cmd_modversions on the as rule? It relies on !defined(__ASSEMBLY__), but we're feeding the result to genksyms, not as. It would require the header be included in the .S file and be protected for asm builds. Stephen wasn't a fan of suck a hack and I can't say I blame him. Another possibility I suppose is an EXPORT_SYMBOL_ASM() variant that takes string containing C function declaration and just inserts it as an assembler comment somewhere that genksysms can find. Thanks, Nick
Re: linux-next: build warnings after merge of the kbuild tree
On 2016-08-19 07:09, Stephen Rothwell wrote: > Hi Nick, > > On Fri, 19 Aug 2016 13:38:54 +1000 Stephen Rothwell> wrote: >> >> On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin wrote: >>> >>> On Wed, 17 Aug 2016 14:59:59 +0200 >>> Michal Marek wrote: >>> On 2016-08-17 03:44, Stephen Rothwell wrote: > > After merging the kbuild tree, today's linux-next build (powerpc > ppc64_defconfig) produced these warnings: > > WARNING: 25 bad relocations > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 [...] > Introduced by commit > > 9445aa1a3062 ("ppc: move exports to definitions") > > I have reverted that commit for today. > > [cc-ing the ppc guys for clues - also involved is commit > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > ] FWIW, I see these warnings as well. Any help from ppc developers is appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm symbols (their CRCs actually)? >>> >>> The dangling relocation is a side effect of linker unable to resolve the >>> reference to the undefined weak symbols. So the real question is, why has >>> genksyms not overridden these symbols with their CRC values? >>> >>> This may not even be powerpc specific, but I'll poke at it a bit more >>> when I get a chance. >> >> Not sure if this is relevant, but with the commit reverted, the >> __crc___... symbols are absolute. >> >> f55b3b3d A __crc___arch_hweight16 > > Ignore that :-) > > I just had a look at a x86_64 allmodconfig result and it looks like the > weak symbols are not resolved their either ... > > I may be missing something, but genksyms generates the crc's off the > preprocessed C source code and we don't have any for the asm files ... Of course you are right. Which means that we are losing type information for these exports for CONFIG_MODVERSIONS purposes. I guess it's acceptable, since the asm functions are pretty basic and their signatures do not change. Michal
Re: linux-next: build warnings after merge of the kbuild tree
On 2016-08-19 07:09, Stephen Rothwell wrote: > Hi Nick, > > On Fri, 19 Aug 2016 13:38:54 +1000 Stephen Rothwell > wrote: >> >> On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin wrote: >>> >>> On Wed, 17 Aug 2016 14:59:59 +0200 >>> Michal Marek wrote: >>> On 2016-08-17 03:44, Stephen Rothwell wrote: > > After merging the kbuild tree, today's linux-next build (powerpc > ppc64_defconfig) produced these warnings: > > WARNING: 25 bad relocations > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 [...] > Introduced by commit > > 9445aa1a3062 ("ppc: move exports to definitions") > > I have reverted that commit for today. > > [cc-ing the ppc guys for clues - also involved is commit > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > ] FWIW, I see these warnings as well. Any help from ppc developers is appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm symbols (their CRCs actually)? >>> >>> The dangling relocation is a side effect of linker unable to resolve the >>> reference to the undefined weak symbols. So the real question is, why has >>> genksyms not overridden these symbols with their CRC values? >>> >>> This may not even be powerpc specific, but I'll poke at it a bit more >>> when I get a chance. >> >> Not sure if this is relevant, but with the commit reverted, the >> __crc___... symbols are absolute. >> >> f55b3b3d A __crc___arch_hweight16 > > Ignore that :-) > > I just had a look at a x86_64 allmodconfig result and it looks like the > weak symbols are not resolved their either ... > > I may be missing something, but genksyms generates the crc's off the > preprocessed C source code and we don't have any for the asm files ... Of course you are right. Which means that we are losing type information for these exports for CONFIG_MODVERSIONS purposes. I guess it's acceptable, since the asm functions are pretty basic and their signatures do not change. Michal
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, 19 Aug 2016 15:09:14 +1000 Stephen Rothwellwrote: > Hi Nick, > > On Fri, 19 Aug 2016 13:38:54 +1000 Stephen Rothwell > wrote: > > > > On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin > > wrote: > > > > > > On Wed, 17 Aug 2016 14:59:59 +0200 > > > Michal Marek wrote: > > > > > > > On 2016-08-17 03:44, Stephen Rothwell wrote: > > > > > > > > > > After merging the kbuild tree, today's linux-next build (powerpc > > > > > ppc64_defconfig) produced these warnings: > > > > > > > > > > WARNING: 25 bad relocations > > > > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > > > > [...] > > > > > Introduced by commit > > > > > > > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > > > > > > > I have reverted that commit for today. > > > > > > > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > > > > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > > > > ] > > > > > > > > FWIW, I see these warnings as well. Any help from ppc developers is > > > > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > > > > symbols (their CRCs actually)? > > > > > > The dangling relocation is a side effect of linker unable to resolve the > > > reference to the undefined weak symbols. So the real question is, why has > > > genksyms not overridden these symbols with their CRC values? > > > > > > This may not even be powerpc specific, but I'll poke at it a bit more > > > when I get a chance. > > > > Not sure if this is relevant, but with the commit reverted, the > > __crc___... symbols are absolute. > > > > f55b3b3d A __crc___arch_hweight16 > > Ignore that :-) > > I just had a look at a x86_64 allmodconfig result and it looks like the > weak symbols are not resolved their either ... > > I may be missing something, but genksyms generates the crc's off the > preprocessed C source code and we don't have any for the asm files ... Looks like you're right, good find! Thanks, Nick
Re: linux-next: build warnings after merge of the kbuild tree
On Fri, 19 Aug 2016 15:09:14 +1000 Stephen Rothwell wrote: > Hi Nick, > > On Fri, 19 Aug 2016 13:38:54 +1000 Stephen Rothwell > wrote: > > > > On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin > > wrote: > > > > > > On Wed, 17 Aug 2016 14:59:59 +0200 > > > Michal Marek wrote: > > > > > > > On 2016-08-17 03:44, Stephen Rothwell wrote: > > > > > > > > > > After merging the kbuild tree, today's linux-next build (powerpc > > > > > ppc64_defconfig) produced these warnings: > > > > > > > > > > WARNING: 25 bad relocations > > > > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > > > > [...] > > > > > Introduced by commit > > > > > > > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > > > > > > > I have reverted that commit for today. > > > > > > > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > > > > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > > > > ] > > > > > > > > FWIW, I see these warnings as well. Any help from ppc developers is > > > > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > > > > symbols (their CRCs actually)? > > > > > > The dangling relocation is a side effect of linker unable to resolve the > > > reference to the undefined weak symbols. So the real question is, why has > > > genksyms not overridden these symbols with their CRC values? > > > > > > This may not even be powerpc specific, but I'll poke at it a bit more > > > when I get a chance. > > > > Not sure if this is relevant, but with the commit reverted, the > > __crc___... symbols are absolute. > > > > f55b3b3d A __crc___arch_hweight16 > > Ignore that :-) > > I just had a look at a x86_64 allmodconfig result and it looks like the > weak symbols are not resolved their either ... > > I may be missing something, but genksyms generates the crc's off the > preprocessed C source code and we don't have any for the asm files ... Looks like you're right, good find! Thanks, Nick
Re: linux-next: build warnings after merge of the kbuild tree
Hi Nick, On Fri, 19 Aug 2016 13:38:54 +1000 Stephen Rothwellwrote: > > On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin wrote: > > > > On Wed, 17 Aug 2016 14:59:59 +0200 > > Michal Marek wrote: > > > > > On 2016-08-17 03:44, Stephen Rothwell wrote: > > > > > > > > After merging the kbuild tree, today's linux-next build (powerpc > > > > ppc64_defconfig) produced these warnings: > > > > > > > > WARNING: 25 bad relocations > > > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > > > [...] > > > > Introduced by commit > > > > > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > > > > > I have reverted that commit for today. > > > > > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > > > ] > > > > > > FWIW, I see these warnings as well. Any help from ppc developers is > > > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > > > symbols (their CRCs actually)? > > > > The dangling relocation is a side effect of linker unable to resolve the > > reference to the undefined weak symbols. So the real question is, why has > > genksyms not overridden these symbols with their CRC values? > > > > This may not even be powerpc specific, but I'll poke at it a bit more > > when I get a chance. > > Not sure if this is relevant, but with the commit reverted, the > __crc___... symbols are absolute. > > f55b3b3d A __crc___arch_hweight16 Ignore that :-) I just had a look at a x86_64 allmodconfig result and it looks like the weak symbols are not resolved their either ... I may be missing something, but genksyms generates the crc's off the preprocessed C source code and we don't have any for the asm files ... -- Cheers, Stephen Rothwell
Re: linux-next: build warnings after merge of the kbuild tree
Hi Nick, On Fri, 19 Aug 2016 13:38:54 +1000 Stephen Rothwell wrote: > > On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin wrote: > > > > On Wed, 17 Aug 2016 14:59:59 +0200 > > Michal Marek wrote: > > > > > On 2016-08-17 03:44, Stephen Rothwell wrote: > > > > > > > > After merging the kbuild tree, today's linux-next build (powerpc > > > > ppc64_defconfig) produced these warnings: > > > > > > > > WARNING: 25 bad relocations > > > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > > > [...] > > > > Introduced by commit > > > > > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > > > > > I have reverted that commit for today. > > > > > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > > > ] > > > > > > FWIW, I see these warnings as well. Any help from ppc developers is > > > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > > > symbols (their CRCs actually)? > > > > The dangling relocation is a side effect of linker unable to resolve the > > reference to the undefined weak symbols. So the real question is, why has > > genksyms not overridden these symbols with their CRC values? > > > > This may not even be powerpc specific, but I'll poke at it a bit more > > when I get a chance. > > Not sure if this is relevant, but with the commit reverted, the > __crc___... symbols are absolute. > > f55b3b3d A __crc___arch_hweight16 Ignore that :-) I just had a look at a x86_64 allmodconfig result and it looks like the weak symbols are not resolved their either ... I may be missing something, but genksyms generates the crc's off the preprocessed C source code and we don't have any for the asm files ... -- Cheers, Stephen Rothwell
Re: linux-next: build warnings after merge of the kbuild tree
Hi Nick, On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Pigginwrote: > > On Wed, 17 Aug 2016 14:59:59 +0200 > Michal Marek wrote: > > > On 2016-08-17 03:44, Stephen Rothwell wrote: > > > > > > After merging the kbuild tree, today's linux-next build (powerpc > > > ppc64_defconfig) produced these warnings: > > > > > > WARNING: 25 bad relocations > > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > > [...] > > > Introduced by commit > > > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > > > I have reverted that commit for today. > > > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > > ] > > > > FWIW, I see these warnings as well. Any help from ppc developers is > > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > > symbols (their CRCs actually)? > > The dangling relocation is a side effect of linker unable to resolve the > reference to the undefined weak symbols. So the real question is, why has > genksyms not overridden these symbols with their CRC values? > > This may not even be powerpc specific, but I'll poke at it a bit more > when I get a chance. Not sure if this is relevant, but with the commit reverted, the __crc___... symbols are absolute. f55b3b3d A __crc___arch_hweight16 -- Cheers, Stephen Rothwell
Re: linux-next: build warnings after merge of the kbuild tree
Hi Nick, On Thu, 18 Aug 2016 11:09:48 +1000 Nicholas Piggin wrote: > > On Wed, 17 Aug 2016 14:59:59 +0200 > Michal Marek wrote: > > > On 2016-08-17 03:44, Stephen Rothwell wrote: > > > > > > After merging the kbuild tree, today's linux-next build (powerpc > > > ppc64_defconfig) produced these warnings: > > > > > > WARNING: 25 bad relocations > > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > > [...] > > > Introduced by commit > > > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > > > I have reverted that commit for today. > > > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > > ] > > > > FWIW, I see these warnings as well. Any help from ppc developers is > > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > > symbols (their CRCs actually)? > > The dangling relocation is a side effect of linker unable to resolve the > reference to the undefined weak symbols. So the real question is, why has > genksyms not overridden these symbols with their CRC values? > > This may not even be powerpc specific, but I'll poke at it a bit more > when I get a chance. Not sure if this is relevant, but with the commit reverted, the __crc___... symbols are absolute. f55b3b3d A __crc___arch_hweight16 -- Cheers, Stephen Rothwell
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, 17 Aug 2016 14:59:59 +0200 Michal Marekwrote: > On 2016-08-17 03:44, Stephen Rothwell wrote: > > Hi Michal, > > > > After merging the kbuild tree, today's linux-next build (powerpc > > ppc64_defconfig) produced these warnings: > > > > WARNING: 25 bad relocations > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > [...] > > Introduced by commit > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > I have reverted that commit for today. > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > ] > > FWIW, I see these warnings as well. Any help from ppc developers is > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > symbols (their CRCs actually)? The dangling relocation is a side effect of linker unable to resolve the reference to the undefined weak symbols. So the real question is, why has genksyms not overridden these symbols with their CRC values? This may not even be powerpc specific, but I'll poke at it a bit more when I get a chance. Thanks, Nick
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, 17 Aug 2016 14:59:59 +0200 Michal Marek wrote: > On 2016-08-17 03:44, Stephen Rothwell wrote: > > Hi Michal, > > > > After merging the kbuild tree, today's linux-next build (powerpc > > ppc64_defconfig) produced these warnings: > > > > WARNING: 25 bad relocations > > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 > [...] > > Introduced by commit > > > > 9445aa1a3062 ("ppc: move exports to definitions") > > > > I have reverted that commit for today. > > > > [cc-ing the ppc guys for clues - also involved is commit > > > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > > ] > > FWIW, I see these warnings as well. Any help from ppc developers is > appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm > symbols (their CRCs actually)? The dangling relocation is a side effect of linker unable to resolve the reference to the undefined weak symbols. So the real question is, why has genksyms not overridden these symbols with their CRC values? This may not even be powerpc specific, but I'll poke at it a bit more when I get a chance. Thanks, Nick
Re: linux-next: build warnings after merge of the kbuild tree
On 2016-08-17 03:44, Stephen Rothwell wrote: > Hi Michal, > > After merging the kbuild tree, today's linux-next build (powerpc > ppc64_defconfig) produced these warnings: > > WARNING: 25 bad relocations > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 [...] > Introduced by commit > > 9445aa1a3062 ("ppc: move exports to definitions") > > I have reverted that commit for today. > > [cc-ing the ppc guys for clues - also involved is commit > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > ] FWIW, I see these warnings as well. Any help from ppc developers is appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm symbols (their CRCs actually)? Thanks, Michal
Re: linux-next: build warnings after merge of the kbuild tree
On 2016-08-17 03:44, Stephen Rothwell wrote: > Hi Michal, > > After merging the kbuild tree, today's linux-next build (powerpc > ppc64_defconfig) produced these warnings: > > WARNING: 25 bad relocations > c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 [...] > Introduced by commit > > 9445aa1a3062 ("ppc: move exports to definitions") > > I have reverted that commit for today. > > [cc-ing the ppc guys for clues - also involved is commit > > 22823ab419d8 ("EXPORT_SYMBOL() for asm") > ] FWIW, I see these warnings as well. Any help from ppc developers is appreciated - should the R_PPC64_ADDR64 be whitelisted for exported asm symbols (their CRCs actually)? Thanks, Michal
linux-next: build warnings after merge of the kbuild tree
Hi Michal, After merging the kbuild tree, today's linux-next build (powerpc ppc64_defconfig) produced these warnings: WARNING: 25 bad relocations c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 c0cf2578 R_PPC64_ADDR64__crc___arch_hweight32 c0cf2580 R_PPC64_ADDR64__crc___arch_hweight64 c0cf2588 R_PPC64_ADDR64__crc___arch_hweight8 c0cf2678 R_PPC64_ADDR64__crc___bswapdi2 c0cf2690 R_PPC64_ADDR64__crc___clear_user c0cf26b8 R_PPC64_ADDR64__crc___copy_tofrom_user c0cf2728 R_PPC64_ADDR64__crc___csum_partial c0cf3f90 R_PPC64_ADDR64__crc_copy_page c0cf40e0 R_PPC64_ADDR64__crc_csum_partial_copy_generic c0cf4100 R_PPC64_ADDR64__crc_current_stack_pointer c0cf4928 R_PPC64_ADDR64__crc_empty_zero_page c0cf4db0 R_PPC64_ADDR64__crc_flush_dcache_range c0cf4dc0 R_PPC64_ADDR64__crc_flush_icache_range c0cf6470 R_PPC64_ADDR64__crc_load_fp_state c0cf6488 R_PPC64_ADDR64__crc_load_vr_state c0cf68d0 R_PPC64_ADDR64__crc_memchr c0cf68e0 R_PPC64_ADDR64__crc_memcmp c0cf68e8 R_PPC64_ADDR64__crc_memcpy c0cf6900 R_PPC64_ADDR64__crc_memmove c0cf6988 R_PPC64_ADDR64__crc_memset c0cf9328 R_PPC64_ADDR64__crc_store_fp_state c0cf9330 R_PPC64_ADDR64__crc_store_vr_state c0cf93d0 R_PPC64_ADDR64__crc_strncmp c0cf93d8 R_PPC64_ADDR64__crc_strncpy Introduced by commit 9445aa1a3062 ("ppc: move exports to definitions") I have reverted that commit for today. [cc-ing the ppc guys for clues - also involved is commit 22823ab419d8 ("EXPORT_SYMBOL() for asm") ] -- Cheers, Stephen Rothwell
linux-next: build warnings after merge of the kbuild tree
Hi Michal, After merging the kbuild tree, today's linux-next build (powerpc ppc64_defconfig) produced these warnings: WARNING: 25 bad relocations c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 c0cf2578 R_PPC64_ADDR64__crc___arch_hweight32 c0cf2580 R_PPC64_ADDR64__crc___arch_hweight64 c0cf2588 R_PPC64_ADDR64__crc___arch_hweight8 c0cf2678 R_PPC64_ADDR64__crc___bswapdi2 c0cf2690 R_PPC64_ADDR64__crc___clear_user c0cf26b8 R_PPC64_ADDR64__crc___copy_tofrom_user c0cf2728 R_PPC64_ADDR64__crc___csum_partial c0cf3f90 R_PPC64_ADDR64__crc_copy_page c0cf40e0 R_PPC64_ADDR64__crc_csum_partial_copy_generic c0cf4100 R_PPC64_ADDR64__crc_current_stack_pointer c0cf4928 R_PPC64_ADDR64__crc_empty_zero_page c0cf4db0 R_PPC64_ADDR64__crc_flush_dcache_range c0cf4dc0 R_PPC64_ADDR64__crc_flush_icache_range c0cf6470 R_PPC64_ADDR64__crc_load_fp_state c0cf6488 R_PPC64_ADDR64__crc_load_vr_state c0cf68d0 R_PPC64_ADDR64__crc_memchr c0cf68e0 R_PPC64_ADDR64__crc_memcmp c0cf68e8 R_PPC64_ADDR64__crc_memcpy c0cf6900 R_PPC64_ADDR64__crc_memmove c0cf6988 R_PPC64_ADDR64__crc_memset c0cf9328 R_PPC64_ADDR64__crc_store_fp_state c0cf9330 R_PPC64_ADDR64__crc_store_vr_state c0cf93d0 R_PPC64_ADDR64__crc_strncmp c0cf93d8 R_PPC64_ADDR64__crc_strncpy Introduced by commit 9445aa1a3062 ("ppc: move exports to definitions") I have reverted that commit for today. [cc-ing the ppc guys for clues - also involved is commit 22823ab419d8 ("EXPORT_SYMBOL() for asm") ] -- Cheers, Stephen Rothwell
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, Jun 9, 2016 at 10:37 AM, Emese Revfywrote: > On Thu, 9 Jun 2016 12:57:16 +0200 > Michal Marek wrote: > >> Dne 9.6.2016 v 06:05 Stephen Rothwell napsal(a): >> > On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cook wrote: >> >> Ah, yes, that should default to off. We'll get a fix landed ASAP. >> > >> > Note that this was an allmodconfig build. The default is 'n', but >> > allmodconfig will turn it on (as will allyesconfig). >> >> I guess we should make GCC_PLUGINS depend on !COMPILE_TEST. Actually I >> thought this was already the case, but it is not. > > Is it really necessary to disable all gcc plugins or would it be enough > to disable only the cyc_complexity plugin? I think disabling (depend on !COMPILE_TEST) plugins that have non-actionable output make sense. For example, in the future, things like constify or initify may produce warnings that are "real" in the sense that they have detected situations that should be fixed in the code. In a perfect world, we would include those fixes ahead of the new plugin to keep Stephen from going crazy. :) -Kees -- Kees Cook Chrome OS & Brillo Security
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, Jun 9, 2016 at 10:37 AM, Emese Revfy wrote: > On Thu, 9 Jun 2016 12:57:16 +0200 > Michal Marek wrote: > >> Dne 9.6.2016 v 06:05 Stephen Rothwell napsal(a): >> > On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cook wrote: >> >> Ah, yes, that should default to off. We'll get a fix landed ASAP. >> > >> > Note that this was an allmodconfig build. The default is 'n', but >> > allmodconfig will turn it on (as will allyesconfig). >> >> I guess we should make GCC_PLUGINS depend on !COMPILE_TEST. Actually I >> thought this was already the case, but it is not. > > Is it really necessary to disable all gcc plugins or would it be enough > to disable only the cyc_complexity plugin? I think disabling (depend on !COMPILE_TEST) plugins that have non-actionable output make sense. For example, in the future, things like constify or initify may produce warnings that are "real" in the sense that they have detected situations that should be fixed in the code. In a perfect world, we would include those fixes ahead of the new plugin to keep Stephen from going crazy. :) -Kees -- Kees Cook Chrome OS & Brillo Security
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, 9 Jun 2016 12:22:58 +1000 Stephen Rothwellwrote: > Hi Michal, > > After merging the kbuild tree, today's linux-next build (x86_64 > allmodconfig) produced these warnings: > > Cyclomatic Complexity 1 scripts/mod/devicetable-offsets.c:main > Cyclomatic Complexity 1 kernel/bounds.c:foo > Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets_64.c:main > Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets.c:common > Cyclomatic Complexity 5 arch/x86/ia32/audit.c:ia32_classify_syscall > > and so on (many, many of these - about 635,000 :-() > > Introduced (presumably) by commits > > 6b90bd4ba40b ("GCC plugin infrastructure") > 0dae776c6bf3 ("Add Cyclomatic complexity GCC plugin") > > I have disabled CONFIG_GCC_PLUGIN_CYC_COMPLEXITY (by making it depend > on CONFIG_BROKEN) until it is not enabled by default. These aren't warnings. This plugin is a static analyzer. It prints out the cyclomatic complexity of all functions in the kernel. I think it would be useful to enable it sometimes and report new functions with a high enough complexity value. -- Emese
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, 9 Jun 2016 12:22:58 +1000 Stephen Rothwell wrote: > Hi Michal, > > After merging the kbuild tree, today's linux-next build (x86_64 > allmodconfig) produced these warnings: > > Cyclomatic Complexity 1 scripts/mod/devicetable-offsets.c:main > Cyclomatic Complexity 1 kernel/bounds.c:foo > Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets_64.c:main > Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets.c:common > Cyclomatic Complexity 5 arch/x86/ia32/audit.c:ia32_classify_syscall > > and so on (many, many of these - about 635,000 :-() > > Introduced (presumably) by commits > > 6b90bd4ba40b ("GCC plugin infrastructure") > 0dae776c6bf3 ("Add Cyclomatic complexity GCC plugin") > > I have disabled CONFIG_GCC_PLUGIN_CYC_COMPLEXITY (by making it depend > on CONFIG_BROKEN) until it is not enabled by default. These aren't warnings. This plugin is a static analyzer. It prints out the cyclomatic complexity of all functions in the kernel. I think it would be useful to enable it sometimes and report new functions with a high enough complexity value. -- Emese
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, 9 Jun 2016 12:57:16 +0200 Michal Marekwrote: > Dne 9.6.2016 v 06:05 Stephen Rothwell napsal(a): > > On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cook wrote: > >> Ah, yes, that should default to off. We'll get a fix landed ASAP. > > > > Note that this was an allmodconfig build. The default is 'n', but > > allmodconfig will turn it on (as will allyesconfig). > > I guess we should make GCC_PLUGINS depend on !COMPILE_TEST. Actually I > thought this was already the case, but it is not. Is it really necessary to disable all gcc plugins or would it be enough to disable only the cyc_complexity plugin? -- Emese
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, 9 Jun 2016 12:57:16 +0200 Michal Marek wrote: > Dne 9.6.2016 v 06:05 Stephen Rothwell napsal(a): > > On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cook wrote: > >> Ah, yes, that should default to off. We'll get a fix landed ASAP. > > > > Note that this was an allmodconfig build. The default is 'n', but > > allmodconfig will turn it on (as will allyesconfig). > > I guess we should make GCC_PLUGINS depend on !COMPILE_TEST. Actually I > thought this was already the case, but it is not. Is it really necessary to disable all gcc plugins or would it be enough to disable only the cyc_complexity plugin? -- Emese
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, 2016-06-09 at 14:05 +1000, Stephen Rothwell wrote: > Hi Kees, > > On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cookwrote: > > > > Congratulations on having the gcc plugin development headers > > successfully installed! ;) > > Thanks :-) And on ppc64le too! (I think) :) cheers
Re: linux-next: build warnings after merge of the kbuild tree
On Thu, 2016-06-09 at 14:05 +1000, Stephen Rothwell wrote: > Hi Kees, > > On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cook wrote: > > > > Congratulations on having the gcc plugin development headers > > successfully installed! ;) > > Thanks :-) And on ppc64le too! (I think) :) cheers
Re: linux-next: build warnings after merge of the kbuild tree
Dne 9.6.2016 v 06:05 Stephen Rothwell napsal(a): > On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cookwrote: >> Ah, yes, that should default to off. We'll get a fix landed ASAP. > > Note that this was an allmodconfig build. The default is 'n', but > allmodconfig will turn it on (as will allyesconfig). I guess we should make GCC_PLUGINS depend on !COMPILE_TEST. Actually I thought this was already the case, but it is not. Michal
Re: linux-next: build warnings after merge of the kbuild tree
Dne 9.6.2016 v 06:05 Stephen Rothwell napsal(a): > On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cook wrote: >> Ah, yes, that should default to off. We'll get a fix landed ASAP. > > Note that this was an allmodconfig build. The default is 'n', but > allmodconfig will turn it on (as will allyesconfig). I guess we should make GCC_PLUGINS depend on !COMPILE_TEST. Actually I thought this was already the case, but it is not. Michal
Re: linux-next: build warnings after merge of the kbuild tree
Hi Kees, On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cookwrote: > > Congratulations on having the gcc plugin development headers > successfully installed! ;) Thanks :-) > Ah, yes, that should default to off. We'll get a fix landed ASAP. Note that this was an allmodconfig build. The default is 'n', but allmodconfig will turn it on (as will allyesconfig). -- Cheers, Stephen Rothwell
Re: linux-next: build warnings after merge of the kbuild tree
Hi Kees, On Wed, 8 Jun 2016 19:56:38 -0700 Kees Cook wrote: > > Congratulations on having the gcc plugin development headers > successfully installed! ;) Thanks :-) > Ah, yes, that should default to off. We'll get a fix landed ASAP. Note that this was an allmodconfig build. The default is 'n', but allmodconfig will turn it on (as will allyesconfig). -- Cheers, Stephen Rothwell
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, Jun 8, 2016 at 7:22 PM, Stephen Rothwellwrote: > Hi Michal, > > After merging the kbuild tree, today's linux-next build (x86_64 > allmodconfig) produced these warnings: > > Cyclomatic Complexity 1 scripts/mod/devicetable-offsets.c:main > Cyclomatic Complexity 1 kernel/bounds.c:foo > Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets_64.c:main > Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets.c:common > Cyclomatic Complexity 5 arch/x86/ia32/audit.c:ia32_classify_syscall > > and so on (many, many of these - about 635,000 :-() Congratulations on having the gcc plugin development headers successfully installed! ;) > Introduced (presumably) by commits > > 6b90bd4ba40b ("GCC plugin infrastructure") > 0dae776c6bf3 ("Add Cyclomatic complexity GCC plugin") > > I have disabled CONFIG_GCC_PLUGIN_CYC_COMPLEXITY (by making it depend > on CONFIG_BROKEN) until it is not enabled by default. Ah, yes, that should default to off. We'll get a fix landed ASAP. -Kees -- Kees Cook Chrome OS & Brillo Security
Re: linux-next: build warnings after merge of the kbuild tree
On Wed, Jun 8, 2016 at 7:22 PM, Stephen Rothwell wrote: > Hi Michal, > > After merging the kbuild tree, today's linux-next build (x86_64 > allmodconfig) produced these warnings: > > Cyclomatic Complexity 1 scripts/mod/devicetable-offsets.c:main > Cyclomatic Complexity 1 kernel/bounds.c:foo > Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets_64.c:main > Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets.c:common > Cyclomatic Complexity 5 arch/x86/ia32/audit.c:ia32_classify_syscall > > and so on (many, many of these - about 635,000 :-() Congratulations on having the gcc plugin development headers successfully installed! ;) > Introduced (presumably) by commits > > 6b90bd4ba40b ("GCC plugin infrastructure") > 0dae776c6bf3 ("Add Cyclomatic complexity GCC plugin") > > I have disabled CONFIG_GCC_PLUGIN_CYC_COMPLEXITY (by making it depend > on CONFIG_BROKEN) until it is not enabled by default. Ah, yes, that should default to off. We'll get a fix landed ASAP. -Kees -- Kees Cook Chrome OS & Brillo Security
linux-next: build warnings after merge of the kbuild tree
Hi Michal, After merging the kbuild tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: Cyclomatic Complexity 1 scripts/mod/devicetable-offsets.c:main Cyclomatic Complexity 1 kernel/bounds.c:foo Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets_64.c:main Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets.c:common Cyclomatic Complexity 5 arch/x86/ia32/audit.c:ia32_classify_syscall and so on (many, many of these - about 635,000 :-() Introduced (presumably) by commits 6b90bd4ba40b ("GCC plugin infrastructure") 0dae776c6bf3 ("Add Cyclomatic complexity GCC plugin") I have disabled CONFIG_GCC_PLUGIN_CYC_COMPLEXITY (by making it depend on CONFIG_BROKEN) until it is not enabled by default. -- Cheers, Stephen Rothwell
linux-next: build warnings after merge of the kbuild tree
Hi Michal, After merging the kbuild tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: Cyclomatic Complexity 1 scripts/mod/devicetable-offsets.c:main Cyclomatic Complexity 1 kernel/bounds.c:foo Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets_64.c:main Cyclomatic Complexity 1 arch/x86/kernel/asm-offsets.c:common Cyclomatic Complexity 5 arch/x86/ia32/audit.c:ia32_classify_syscall and so on (many, many of these - about 635,000 :-() Introduced (presumably) by commits 6b90bd4ba40b ("GCC plugin infrastructure") 0dae776c6bf3 ("Add Cyclomatic complexity GCC plugin") I have disabled CONFIG_GCC_PLUGIN_CYC_COMPLEXITY (by making it depend on CONFIG_BROKEN) until it is not enabled by default. -- Cheers, Stephen Rothwell