[GIT PULL] kbuild changes for v4.9-rc1

[GIT PULL] kbuild changes for v4.9-rc1

[Michal Marek]

Hi Linus,

please pull these kbuild changes for v4.9-rc1:

- EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression,
  because genksyms no longer generates checksums for these symbols
  (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this.
  Plus, we are talking about functions like strcpy(), which rarely
  change prototypes.
- Fixes for PPC fallout of the above by Stephen Rothwell and Nick Piggin
- fixdep speedup by Alexey Dobriyan.
- Preparatory work by Nick Piggin to allow architectures to build with
  -ffunction-sections, -fdata-sections and --gc-sections
- CONFIG_THIN_ARCHIVES support by Stephen Rothwell
- Fix for filenames with colons in the initramfs source by me.


The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kbuild

for you to fetch changes up to 590abbdd273304b55824bcb9ea91840ea375575d:

  initramfs: Escape colons in depfile (2016-09-23 10:35:32 +0200)

----------------------------------------------------------------
Al Viro (12):
      [kbuild] handle exports in lib-y objects reliably
      EXPORT_SYMBOL() for asm
      x86: move exports to actual definitions
      alpha: move exports to actual definitions
      m68k: move exports to definitions
      s390: move exports to definitions
      arm: move exports to definitions
      ppc: move exports to definitions
      sparc: move exports to definitions
      [sparc] unify 32bit and 64bit string.h
      sparc32: debride memcpy.S a bit
      ia64: move exports to definitions

Alexey Dobriyan (1):
      fixdep: faster CONFIG_ search

Michal Marek (2):
      kbuild: Regenerate genksyms lexer
      initramfs: Escape colons in depfile

Nicholas Piggin (5):
      kbuild: genksyms fix for typeof handling
      kbuild: allow archs to select link dead code/data elimination
      kbuild: add arch specific post-link Makefile
      kbuild: -ffunction-sections fix for archs with conflicting sections
      powerpc/64: whitelist unresolved modversions CRCs

Stephen Rothwell (2):
      kbuild: allow architectures to use thin archives instead of ld -r
      ppc: there is no clear_pages to export

 Documentation/kbuild/makefiles.txt    |  16 +++
 Makefile                              |  19 +++-
 arch/Kconfig                          |  21 ++++
 arch/alpha/include/asm/Kbuild         |   1 +
 arch/alpha/kernel/Makefile            |   2 +-
 arch/alpha/kernel/alpha_ksyms.c       | 102 -------------------
 arch/alpha/kernel/machvec_impl.h      |   6 +-
 arch/alpha/kernel/setup.c             |   1 +
 arch/alpha/lib/callback_srm.S         |   5 +
 arch/alpha/lib/checksum.c             |   3 +
 arch/alpha/lib/clear_page.S           |   3 +-
 arch/alpha/lib/clear_user.S           |   2 +
 arch/alpha/lib/copy_page.S            |   3 +-
 arch/alpha/lib/copy_user.S            |   3 +
 arch/alpha/lib/csum_ipv6_magic.S      |   2 +
 arch/alpha/lib/csum_partial_copy.c    |   2 +
 arch/alpha/lib/dec_and_lock.c         |   2 +
 arch/alpha/lib/divide.S               |   3 +
 arch/alpha/lib/ev6-clear_page.S       |   3 +-
 arch/alpha/lib/ev6-clear_user.S       |   3 +-
 arch/alpha/lib/ev6-copy_page.S        |   3 +-
 arch/alpha/lib/ev6-copy_user.S        |   3 +-
 arch/alpha/lib/ev6-csum_ipv6_magic.S  |   2 +
 arch/alpha/lib/ev6-divide.S           |   3 +
 arch/alpha/lib/ev6-memchr.S           |   3 +-
 arch/alpha/lib/ev6-memcpy.S           |   3 +-
 arch/alpha/lib/ev6-memset.S           |   7 +-
 arch/alpha/lib/ev67-strcat.S          |   3 +-
 arch/alpha/lib/ev67-strchr.S          |   3 +-
 arch/alpha/lib/ev67-strlen.S          |   3 +-
 arch/alpha/lib/ev67-strncat.S         |   3 +-
 arch/alpha/lib/ev67-strrchr.S         |   3 +-
 arch/alpha/lib/fpreg.c                |   7 ++
 arch/alpha/lib/memchr.S               |   3 +-
 arch/alpha/lib/memcpy.c               |   5 +-
 arch/alpha/lib/memmove.S              |   3 +-
 arch/alpha/lib/memset.S               |   7 +-
 arch/alpha/lib/strcat.S               |   2 +
 arch/alpha/lib/strchr.S               |   3 +-
 arch/alpha/lib/strcpy.S               |   3 +-
 arch/alpha/lib/strlen.S               |   3 +-
 arch/alpha/lib/strncat.S              |   3 +-
 arch/alpha/lib/strncpy.S              |   3 +-
 arch/alpha/lib/strrchr.S              |   3 +-
 arch/arm/include/asm/Kbuild           |   1 +
 arch/arm/kernel/Makefile              |   2 +-
 arch/arm/kernel/armksyms.c            | 183 ----------------------------------
 arch/arm/kernel/entry-ftrace.S        |   3 +
 arch/arm/kernel/head.S                |   3 +
 arch/arm/kernel/smccc-call.S          |   3 +
 arch/arm/lib/ashldi3.S                |   3 +
 arch/arm/lib/ashrdi3.S                |   3 +
 arch/arm/lib/bitops.h                 |   5 +
 arch/arm/lib/bswapsdi2.S              |   3 +
 arch/arm/lib/clear_user.S             |   4 +
 arch/arm/lib/copy_from_user.S         |   2 +
 arch/arm/lib/copy_page.S              |   2 +
 arch/arm/lib/copy_to_user.S           |   4 +
 arch/arm/lib/csumipv6.S               |   3 +-
 arch/arm/lib/csumpartial.S            |   2 +
 arch/arm/lib/csumpartialcopy.S        |   1 +
 arch/arm/lib/csumpartialcopygeneric.S |   2 +
 arch/arm/lib/csumpartialcopyuser.S    |   1 +
 arch/arm/lib/delay.c                  |   2 +
 arch/arm/lib/div64.S                  |   2 +
 arch/arm/lib/findbit.S                |   9 ++
 arch/arm/lib/getuser.S                |   9 ++
 arch/arm/lib/io-readsb.S              |   2 +
 arch/arm/lib/io-readsl.S              |   2 +
 arch/arm/lib/io-readsw-armv3.S        |   3 +-
 arch/arm/lib/io-readsw-armv4.S        |   2 +
 arch/arm/lib/io-writesb.S             |   2 +
 arch/arm/lib/io-writesl.S             |   2 +
 arch/arm/lib/io-writesw-armv3.S       |   2 +
 arch/arm/lib/io-writesw-armv4.S       |   2 +
 arch/arm/lib/lib1funcs.S              |   9 ++
 arch/arm/lib/lshrdi3.S                |   3 +
 arch/arm/lib/memchr.S                 |   2 +
 arch/arm/lib/memcpy.S                 |   3 +
 arch/arm/lib/memmove.S                |   2 +
 arch/arm/lib/memset.S                 |   3 +
 arch/arm/lib/memzero.S                |   2 +
 arch/arm/lib/muldi3.S                 |   3 +
 arch/arm/lib/putuser.S                |   5 +
 arch/arm/lib/strchr.S                 |   2 +
 arch/arm/lib/strrchr.S                |   2 +
 arch/arm/lib/uaccess_with_memcpy.c    |   3 +
 arch/arm/lib/ucmpdi2.S                |   3 +
 arch/arm/mach-imx/Makefile            |   1 -
 arch/arm/mach-imx/ssi-fiq-ksym.c      |  20 ----
 arch/arm/mach-imx/ssi-fiq.S           |   7 +-
 arch/ia64/hp/sim/boot/Makefile        |   2 +-
 arch/ia64/include/asm/export.h        |   3 +
 arch/ia64/kernel/entry.S              |   3 +
 arch/ia64/kernel/esi_stub.S           |   2 +
 arch/ia64/kernel/head.S               |   2 +
 arch/ia64/kernel/ia64_ksyms.c         |  94 +----------------
 arch/ia64/kernel/ivt.S                |   2 +
 arch/ia64/kernel/pal.S                |   7 ++
 arch/ia64/kernel/setup.c              |   4 +
 arch/ia64/lib/Makefile                |   8 +-
 arch/ia64/lib/clear_page.S            |   2 +
 arch/ia64/lib/clear_user.S            |   2 +
 arch/ia64/lib/copy_page.S             |   2 +
 arch/ia64/lib/copy_page_mck.S         |   2 +
 arch/ia64/lib/copy_user.S             |   2 +
 arch/ia64/lib/flush.S                 |   2 +
 arch/ia64/lib/idiv32.S                |   2 +
 arch/ia64/lib/idiv64.S                |   2 +
 arch/ia64/lib/ip_fast_csum.S          |   3 +
 arch/ia64/lib/memcpy.S                |   2 +
 arch/ia64/lib/memcpy_mck.S            |   3 +
 arch/ia64/lib/memset.S                |   2 +
 arch/ia64/lib/strlen.S                |   2 +
 arch/ia64/lib/strlen_user.S           |   2 +
 arch/ia64/lib/strncpy_from_user.S     |   2 +
 arch/ia64/lib/strnlen_user.S          |   2 +
 arch/ia64/lib/xor.S                   |   5 +
 arch/m68k/include/asm/export.h        |   3 +
 arch/m68k/kernel/Makefile             |   2 +-
 arch/m68k/kernel/m68k_ksyms.c         |  32 ------
 arch/m68k/lib/ashldi3.c               |   4 +
 arch/m68k/lib/ashrdi3.c               |   4 +
 arch/m68k/lib/divsi3.S                |   3 +
 arch/m68k/lib/lshrdi3.c               |   4 +
 arch/m68k/lib/modsi3.S                |   3 +
 arch/m68k/lib/muldi3.c                |   4 +
 arch/m68k/lib/mulsi3.S                |   4 +-
 arch/m68k/lib/udivsi3.S               |   4 +-
 arch/m68k/lib/umodsi3.S               |   4 +-
 arch/powerpc/include/asm/Kbuild       |   1 +
 arch/powerpc/kernel/Makefile          |   4 -
 arch/powerpc/kernel/entry_32.S        |   2 +
 arch/powerpc/kernel/entry_64.S        |   3 +
 arch/powerpc/kernel/epapr_hcalls.S    |   2 +
 arch/powerpc/kernel/fpu.S             |   3 +
 arch/powerpc/kernel/head_32.S         |   5 +
 arch/powerpc/kernel/head_40x.S        |   2 +
 arch/powerpc/kernel/head_44x.S        |   2 +
 arch/powerpc/kernel/head_64.S         |   2 +
 arch/powerpc/kernel/head_8xx.S        |   2 +
 arch/powerpc/kernel/head_fsl_booke.S  |   2 +
 arch/powerpc/kernel/misc.S            |   2 +
 arch/powerpc/kernel/misc_32.S         |  10 ++
 arch/powerpc/kernel/misc_64.S         |   4 +
 arch/powerpc/kernel/pci-common.c      |   1 +
 arch/powerpc/kernel/pci_32.c          |   2 +
 arch/powerpc/kernel/ppc_ksyms.c       |  37 -------
 arch/powerpc/kernel/ppc_ksyms_32.c    |  60 -----------
 arch/powerpc/kernel/setup_32.c        |   6 ++
 arch/powerpc/kernel/time.c            |   1 +
 arch/powerpc/kernel/vector.S          |   3 +
 arch/powerpc/lib/Makefile             |   2 +-
 arch/powerpc/lib/checksum_32.S        |   3 +
 arch/powerpc/lib/checksum_64.S        |   3 +
 arch/powerpc/lib/copy_32.S            |   5 +
 arch/powerpc/lib/copypage_64.S        |   2 +
 arch/powerpc/lib/copyuser_64.S        |   2 +
 arch/powerpc/lib/hweight_64.S         |   5 +
 arch/powerpc/lib/mem_64.S             |   3 +
 arch/powerpc/lib/memcmp_64.S          |   2 +
 arch/powerpc/lib/memcpy_64.S          |   2 +
 arch/powerpc/lib/ppc_ksyms.c          |  29 ------
 arch/powerpc/lib/string.S             |   6 ++
 arch/powerpc/lib/string_64.S          |   2 +
 arch/powerpc/mm/hash_low_32.S         |   3 +
 arch/powerpc/relocs_check.sh          |   4 +-
 arch/powerpc/sysdev/dcr-low.S         |   3 +
 arch/s390/include/asm/Kbuild          |   1 +
 arch/s390/kernel/Makefile             |   2 +-
 arch/s390/kernel/entry.S              |   6 ++
 arch/s390/kernel/mcount.S             |   3 +
 arch/s390/kernel/s390_ksyms.c         |  15 ---
 arch/s390/lib/mem.S                   |   3 +
 arch/sparc/include/asm/Kbuild         |   1 +
 arch/sparc/include/asm/string.h       |  34 +++++++
 arch/sparc/include/asm/string_32.h    |  56 -----------
 arch/sparc/include/asm/string_64.h    |  44 --------
 arch/sparc/kernel/Makefile            |   2 +-
 arch/sparc/kernel/entry.S             |   3 +
 arch/sparc/kernel/head_32.S           |   3 +
 arch/sparc/kernel/head_64.S           |   7 +-
 arch/sparc/kernel/helpers.S           |   2 +
 arch/sparc/kernel/hvcalls.S           |   5 +
 arch/sparc/kernel/sparc_ksyms.c       |  12 +++
 arch/sparc/kernel/sparc_ksyms_32.c    |  31 ------
 arch/sparc/kernel/sparc_ksyms_64.c    |  53 ----------
 arch/sparc/lib/Makefile               |   1 -
 arch/sparc/lib/U1memcpy.S             |   2 +
 arch/sparc/lib/VISsave.S              |   2 +
 arch/sparc/lib/ashldi3.S              |   2 +
 arch/sparc/lib/ashrdi3.S              |   2 +
 arch/sparc/lib/atomic_64.S            |  16 ++-
 arch/sparc/lib/bitops.S               |   7 ++
 arch/sparc/lib/blockops.S             |   3 +
 arch/sparc/lib/bzero.S                |   4 +
 arch/sparc/lib/checksum_32.S          |   3 +
 arch/sparc/lib/checksum_64.S          |   2 +
 arch/sparc/lib/clear_page.S           |   3 +
 arch/sparc/lib/copy_in_user.S         |   2 +
 arch/sparc/lib/copy_page.S            |   2 +
 arch/sparc/lib/copy_user.S            |   2 +
 arch/sparc/lib/csum_copy.S            |   3 +
 arch/sparc/lib/divdi3.S               |   2 +
 arch/sparc/lib/ffs.S                  |   3 +
 arch/sparc/lib/hweight.S              |   5 +
 arch/sparc/lib/ipcsum.S               |   2 +
 arch/sparc/lib/ksyms.c                | 174 --------------------------------
 arch/sparc/lib/locks.S                |   5 +
 arch/sparc/lib/lshrdi3.S              |   2 +
 arch/sparc/lib/mcount.S               |   2 +
 arch/sparc/lib/memcmp.S               |   2 +
 arch/sparc/lib/memcpy.S               |  86 +---------------
 arch/sparc/lib/memmove.S              |   2 +
 arch/sparc/lib/memscan_32.S           |   4 +
 arch/sparc/lib/memscan_64.S           |   4 +
 arch/sparc/lib/memset.S               |   3 +
 arch/sparc/lib/muldi3.S               |   2 +
 arch/sparc/lib/strlen.S               |   2 +
 arch/sparc/lib/strncmp_32.S           |   2 +
 arch/sparc/lib/strncmp_64.S           |   2 +
 arch/sparc/lib/xor.S                  |   9 ++
 arch/x86/entry/entry_32.S             |   2 +
 arch/x86/entry/entry_64.S             |   2 +
 arch/x86/entry/thunk_32.S             |   3 +
 arch/x86/entry/thunk_64.S             |   3 +
 arch/x86/include/asm/export.h         |   4 +
 arch/x86/kernel/Makefile              |   4 +-
 arch/x86/kernel/head_32.S             |   2 +
 arch/x86/kernel/head_64.S             |   3 +
 arch/x86/kernel/i386_ksyms_32.c       |  47 ---------
 arch/x86/kernel/mcount_64.S           |   2 +
 arch/x86/kernel/x8664_ksyms_64.c      |  85 ----------------
 arch/x86/lib/checksum_32.S            |   3 +
 arch/x86/lib/clear_page_64.S          |   2 +
 arch/x86/lib/cmpxchg8b_emu.S          |   2 +
 arch/x86/lib/copy_page_64.S           |   2 +
 arch/x86/lib/copy_user_64.S           |   8 ++
 arch/x86/lib/csum-partial_64.c        |   1 +
 arch/x86/lib/getuser.S                |   5 +
 arch/x86/lib/hweight.S                |   3 +
 arch/x86/lib/memcpy_64.S              |   4 +
 arch/x86/lib/memmove_64.S             |   3 +
 arch/x86/lib/memset_64.S              |   3 +
 arch/x86/lib/putuser.S                |   5 +
 arch/x86/lib/strstr_32.c              |   3 +-
 arch/x86/um/Makefile                  |   2 +-
 arch/x86/um/checksum_32.S             |   2 +
 arch/x86/um/ksyms.c                   |  13 ---
 include/asm-generic/export.h          |  94 +++++++++++++++++
 include/asm-generic/vmlinux.lds.h     |  57 ++++++-----
 include/linux/compiler.h              |  23 +++++
 include/linux/export.h                |  30 +++---
 include/linux/init.h                  |  38 +++----
 init/Makefile                         |   2 +
 scripts/Makefile.build                |  43 +++++++-
 scripts/Makefile.modpost              |  14 ++-
 scripts/basic/fixdep.c                |  86 ++++++----------
 scripts/gen_initramfs_list.sh         |   5 +-
 scripts/genksyms/lex.l                |  35 ++++---
 scripts/genksyms/lex.lex.c_shipped    |  35 ++++---
 scripts/link-vmlinux.sh               |  71 +++++++++++--
 262 files changed, 1094 insertions(+), 1403 deletions(-)
 delete mode 100644 arch/alpha/kernel/alpha_ksyms.c
 delete mode 100644 arch/arm/kernel/armksyms.c
 delete mode 100644 arch/arm/mach-imx/ssi-fiq-ksym.c
 create mode 100644 arch/ia64/include/asm/export.h
 create mode 100644 arch/m68k/include/asm/export.h
 delete mode 100644 arch/m68k/kernel/m68k_ksyms.c
 delete mode 100644 arch/powerpc/kernel/ppc_ksyms.c
 delete mode 100644 arch/powerpc/kernel/ppc_ksyms_32.c
 delete mode 100644 arch/powerpc/lib/ppc_ksyms.c
 delete mode 100644 arch/s390/kernel/s390_ksyms.c
 create mode 100644 arch/sparc/kernel/sparc_ksyms.c
 delete mode 100644 arch/sparc/kernel/sparc_ksyms_32.c
 delete mode 100644 arch/sparc/kernel/sparc_ksyms_64.c
 delete mode 100644 arch/sparc/lib/ksyms.c
 create mode 100644 arch/x86/include/asm/export.h
 delete mode 100644 arch/x86/kernel/i386_ksyms_32.c
 delete mode 100644 arch/x86/kernel/x8664_ksyms_64.c
 delete mode 100644 arch/x86/um/ksyms.c
 create mode 100644 include/asm-generic/export.h

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nicholas Piggin]

On Sat, 15 Oct 2016 17:22:05 -0700
Omar Sandoval <osandov@osandov.com> wrote:

> On Fri, Oct 14, 2016 at 10:12:46PM +0200, Michal Marek wrote:
> > Hi Linus,
> > 
> > please pull these kbuild changes for v4.9-rc1:
> > 
> > - EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression,
> >   because genksyms no longer generates checksums for these symbols
> >   (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this.
> >   Plus, we are talking about functions like strcpy(), which rarely
> >   change prototypes.  
> 
> So this has broken all module loading for me. I get the following dmesg
> spew:
> 
> ...
> [    4.586914] scsi_mod: no symbol version for memset
> [    4.587920] scsi_mod: Unknown symbol memset (err -22)
> [    4.588443] scsi_mod: no symbol version for ___preempt_schedule
> [    4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
> ...
> 
> Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
> it for me. This is with GCC 6.2.1, binutils 2.27, attached config.
> 

Thanks for the report. Could you try this patch and see if it helps?


Allow architectures to create asm/asm-prototypes.h file that
provides C prototypes for exported asm functions, which enables
proper CRC versions to be generated for them.

It's done by creating a trivial C program that includes that file
and the EXPORT_SYMBOL()s from the .S file, and preprocesses that
then sends the result to genksyms.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
 scripts/Makefile.build | 71 +++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 65 insertions(+), 6 deletions(-)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index de46ab0..edcf876 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -159,7 +159,8 @@ cmd_cpp_i_c       = $(CPP) $(c_flags) -o $@ $<
 $(obj)/%.i: $(src)/%.c FORCE
 	$(call if_changed_dep,cpp_i_c)
 
-cmd_gensymtypes =                                                           \
+# These mirror gensymtypes_S and co below, keep them in synch.
+cmd_gensymtypes_c =                                                         \
     $(CPP) -D__GENKSYMS__ $(c_flags) $< |                                   \
     $(GENKSYMS) $(if $(1), -T $(2))                                         \
      $(patsubst y,-s _,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX))             \
@@ -169,7 +170,7 @@ cmd_gensymtypes =                                                           \
 quiet_cmd_cc_symtypes_c = SYM $(quiet_modtag) $@
 cmd_cc_symtypes_c =                                                         \
     set -e;                                                                 \
-    $(call cmd_gensymtypes,true,$@) >/dev/null;                             \
+    $(call cmd_gensymtypes_c,true,$@) >/dev/null;                           \
     test -s $@ || rm -f $@
 
 $(obj)/%.symtypes : $(src)/%.c FORCE
@@ -198,9 +199,10 @@ else
 #   the actual value of the checksum generated by genksyms
 
 cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $<
-cmd_modversions =								\
+
+cmd_modversions_c =								\
 	if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then		\
-		$(call cmd_gensymtypes,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))	\
+		$(call cmd_gensymtypes_c,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))	\
 		    > $(@D)/.tmp_$(@F:.o=.ver);					\
 										\
 		$(LD) $(LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F) 			\
@@ -268,13 +270,14 @@ endif # CONFIG_STACK_VALIDATION
 define rule_cc_o_c
 	$(call echo-cmd,checksrc) $(cmd_checksrc)			  \
 	$(call cmd_and_fixdep,cc_o_c)					  \
-	$(cmd_modversions)						  \
+	$(cmd_modversions_c)						  \
 	$(cmd_objtool)						          \
 	$(call echo-cmd,record_mcount) $(cmd_record_mcount)
 endef
 
 define rule_as_o_S
 	$(call cmd_and_fixdep,as_o_S)					  \
+	$(cmd_modversions_S)						  \
 	$(cmd_objtool)
 endef
 
@@ -314,6 +317,32 @@ modkern_aflags := $(KBUILD_AFLAGS_KERNEL) $(AFLAGS_KERNEL)
 $(real-objs-m)      : modkern_aflags := $(KBUILD_AFLAGS_MODULE) $(AFLAGS_MODULE)
 $(real-objs-m:.o=.s): modkern_aflags := $(KBUILD_AFLAGS_MODULE) $(AFLAGS_MODULE)
 
+# .S file exports must have their C prototypes defined in asm/asm-prototypes.h
+# or a file that it includes, in order to get versioned symbols. We build a
+# dummy C file that includes asm-prototypes and the EXPORT_SYMBOL lines from
+# the .S file (with trailing ';'), and run genksyms on that, to extract vers.
+#
+# These mirror gensymtypes_c and co above, keep them in synch.
+cmd_gensymtypes_S =                                                         \
+    (echo "\#include <linux/kernel.h>" ;                                    \
+     echo "\#include <asm/asm-prototypes.h>" ;                              \
+     grep EXPORT_SYMBOL $< | sed 's/$$/;/' ) |                              \
+    $(CPP) -D__GENKSYMS__ $(c_flags) -xc - |                                \
+    $(GENKSYMS) $(if $(1), -T $(2))                                         \
+     $(patsubst y,-s _,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX))             \
+     $(if $(KBUILD_PRESERVE),-p)                                            \
+     -r $(firstword $(wildcard $(2:.symtypes=.symref) /dev/null))
+
+quiet_cmd_cc_symtypes_S = SYM $(quiet_modtag) $@
+cmd_cc_symtypes_S =                                                         \
+    set -e;                                                                 \
+    $(call cmd_gensymtypes_S,true,$@) >/dev/null;                           \
+    test -s $@ || rm -f $@
+
+$(obj)/%.symtypes : $(src)/%.S FORCE
+	$(call cmd,cc_symtypes_S)
+
+
 quiet_cmd_cpp_s_S = CPP $(quiet_modtag) $@
 cmd_cpp_s_S       = $(CPP) $(a_flags) -o $@ $<
 
@@ -321,7 +350,37 @@ $(obj)/%.s: $(src)/%.S FORCE
 	$(call if_changed_dep,cpp_s_S)
 
 quiet_cmd_as_o_S = AS $(quiet_modtag)  $@
-cmd_as_o_S       = $(CC) $(a_flags) -c -o $@ $<
+
+ifndef CONFIG_MODVERSIONS
+cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $<
+
+else
+
+ASM_PROTOTYPES := $(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/asm-prototypes.h)
+
+ifeq ($(ASM_PROTOTYPES),)
+cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $<
+
+else
+
+# versioning matches the C process described above, with difference that
+# we parse asm-prototypes.h C header to get function definitions.
+
+cmd_as_o_S = $(CC) $(a_flags) -c -o $(@D)/.tmp_$(@F) $<
+
+cmd_modversions_S =								\
+	if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then		\
+		$(call cmd_gensymtypes_S,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))	\
+		    > $(@D)/.tmp_$(@F:.o=.ver);					\
+										\
+		$(LD) $(LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F) 			\
+			-T $(@D)/.tmp_$(@F:.o=.ver);				\
+		rm -f $(@D)/.tmp_$(@F) $(@D)/.tmp_$(@F:.o=.ver);		\
+	else									\
+		mv -f $(@D)/.tmp_$(@F) $@;					\
+	fi;
+endif
+endif
 
 $(obj)/%.o: $(src)/%.S $(objtool_obj) FORCE
 	$(call if_changed_rule,as_o_S)
-- 
2.9.3

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Adam Borowski]

On Mon, Oct 17, 2016 at 02:57:09PM +1100, Nicholas Piggin wrote:
> On Sat, 15 Oct 2016 17:22:05 -0700 Omar Sandoval <osandov@osandov.com> wrote:
> > On Fri, Oct 14, 2016 at 10:12:46PM +0200, Michal Marek wrote:
> > > please pull these kbuild changes for v4.9-rc1:
> > > 
> > > - EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression,
> > >   because genksyms no longer generates checksums for these symbols
> > >   (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this.
> > >   Plus, we are talking about functions like strcpy(), which rarely
> > >   change prototypes.  
> > 
> > So this has broken all module loading for me. I get the following dmesg
> > spew:
> > ...
> > [    4.586914] scsi_mod: no symbol version for memset
> > [    4.587920] scsi_mod: Unknown symbol memset (err -22)
> > [    4.588443] scsi_mod: no symbol version for ___preempt_schedule
> > [    4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
> > ...
> > 
> > Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
> > it for me. This is with GCC 6.2.1, binutils 2.27, attached config.
> 
> Thanks for the report. Could you try this patch and see if it helps?
[patch snipped]

Omar probably won't wake up in quite a while, so I've tested the patch.
Alas, doesn't help.  Similar spew (for the few modules I don't have =y),
while reverting 784d5699eddc fixes it for me too.

Debian sid toolchain: gcc 6.2.0-6, binutils 2.27-8, config at
https://angband.pl/tmp/config-4.9.0-rc1-debug+.gz


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Mathieu OTHACEHE]

Hi,

>> Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
>> it for me. This is with GCC 6.2.1, binutils 2.27, attached config.

I've had the same problem. Reverting your binutils from 2.27 to 2.26,
will also fix it. It seems ld 2.27 is not merging weak symbols from .o
files to vmlinux when linking.

Anyhow all crc for symbols exported from .S will be 0, so Nicholas
patch make sense.

Mathieu

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nicholas Piggin]

On Mon, 17 Oct 2016 08:51:31 +0200
Adam Borowski <kilobyte@angband.pl> wrote:

> On Mon, Oct 17, 2016 at 02:57:09PM +1100, Nicholas Piggin wrote:
> > On Sat, 15 Oct 2016 17:22:05 -0700 Omar Sandoval <osandov@osandov.com> wrote:  
> > > On Fri, Oct 14, 2016 at 10:12:46PM +0200, Michal Marek wrote:  
> > > > please pull these kbuild changes for v4.9-rc1:
> > > > 
> > > > - EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression,
> > > >   because genksyms no longer generates checksums for these symbols
> > > >   (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this.
> > > >   Plus, we are talking about functions like strcpy(), which rarely
> > > >   change prototypes.    
> > > 
> > > So this has broken all module loading for me. I get the following dmesg
> > > spew:
> > > ...
> > > [    4.586914] scsi_mod: no symbol version for memset
> > > [    4.587920] scsi_mod: Unknown symbol memset (err -22)
> > > [    4.588443] scsi_mod: no symbol version for ___preempt_schedule
> > > [    4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
> > > ...
> > > 
> > > Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
> > > it for me. This is with GCC 6.2.1, binutils 2.27, attached config.  
> > 
> > Thanks for the report. Could you try this patch and see if it helps?  
> [patch snipped]
> 
> Omar probably won't wake up in quite a while, so I've tested the patch.
> Alas, doesn't help.  Similar spew (for the few modules I don't have =y),
> while reverting 784d5699eddc fixes it for me too.
> 
> Debian sid toolchain: gcc 6.2.0-6, binutils 2.27-8, config at
> https://angband.pl/tmp/config-4.9.0-rc1-debug+.gz

Forgot to engage my brain before posting.

Architectures will need to have an include/asm/asm-prototypes.h that
defines or #include<>s C-style prototypes for exported asm functions.
We can do an asm-generic version for the common ones like memset so
there's not a lot of pointless duplication there.

Care to do a patch for x86?

Thanks,
Nick

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Adam Borowski]

On Mon, Oct 17, 2016 at 05:59:51PM +1100, Nicholas Piggin wrote:
> On Mon, 17 Oct 2016 08:51:31 +0200
> Adam Borowski <kilobyte@angband.pl> wrote:
> > On Mon, Oct 17, 2016 at 02:57:09PM +1100, Nicholas Piggin wrote:
> > > On Sat, 15 Oct 2016 17:22:05 -0700 Omar Sandoval <osandov@osandov.com> wrote:  
> > > > So this has broken all module loading for me. I get the following dmesg
> > > > spew:
> > > > ...
> > > > [    4.586914] scsi_mod: no symbol version for memset
> > > > [    4.587920] scsi_mod: Unknown symbol memset (err -22)
> > > > [    4.588443] scsi_mod: no symbol version for ___preempt_schedule
> > > > [    4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
> > > > ...
> > > > 
> > > > Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
> > > > it for me. This is with GCC 6.2.1, binutils 2.27, attached config.  
> > > 
> > > Thanks for the report. Could you try this patch and see if it helps?  
> > [patch snipped]
> > 
> > Omar probably won't wake up in quite a while, so I've tested the patch.
> > Alas, doesn't help.  Similar spew (for the few modules I don't have =y),
> > while reverting 784d5699eddc fixes it for me too.
> 
> Forgot to engage my brain before posting.
> 
> Architectures will need to have an include/asm/asm-prototypes.h that
> defines or #include<>s C-style prototypes for exported asm functions.
> We can do an asm-generic version for the common ones like memset so
> there's not a lot of pointless duplication there.
> 
> Care to do a patch for x86?

Sure, did so.  With the prototypes added, your patch works!
Tested on a handful of modules, and one out-of-tree (virtualbox).
I didn't try a 32-bit build.

Note that powerpc already has an include/asm/asm-prototypes.h which might or
might not be what you want.  It doesn't have memset and co, for example.

Anyway, here's my stab at x86:


From db746df65b920591606398b4b244f5b6dc9eea04 Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilobyte@angband.pl>
Date: Mon, 17 Oct 2016 11:42:35 +0200
Subject: [PATCH] kbuild: provide include/asm/asm-prototypes.h for x86

Nicholas Piggin wrote:
> Architectures will need to have an include/asm/asm-prototypes.h that
> defines or #include<>s C-style prototypes for exported asm functions.
> We can do an asm-generic version for the common ones like memset so
> there's not a lot of pointless duplication there.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 arch/x86/include/asm/asm-prototypes.h | 13 +++++++++++++
 include/asm-generic/asm-prototypes.h  |  7 +++++++
 2 files changed, 20 insertions(+)
 create mode 100644 arch/x86/include/asm/asm-prototypes.h
 create mode 100644 include/asm-generic/asm-prototypes.h

diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/asm-prototypes.h
new file mode 100644
index 0000000..072c97c
--- /dev/null
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -0,0 +1,13 @@
+#include <asm/ftrace.h>
+#include <asm/uaccess.h>
+#include <asm/uaccess.h>
+#include <asm/string.h>
+#include <asm/page.h>
+#include <asm/checksum.h>
+
+#include <asm-generic/asm-prototypes.h>
+
+#include <asm/page.h>
+#include <asm/pgtable.h>
+#include <asm/special_insns.h>
+#include <asm/preempt.h>
diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
new file mode 100644
index 0000000..df13637
--- /dev/null
+++ b/include/asm-generic/asm-prototypes.h
@@ -0,0 +1,7 @@
+#include <linux/bitops.h>
+extern void *__memset(void *, int, __kernel_size_t);
+extern void *__memcpy(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *, const void *, __kernel_size_t);
+extern void *memset(void *, int, __kernel_size_t);
+extern void *memcpy(void *, const void *, __kernel_size_t);
+extern void *memmove(void *, const void *, __kernel_size_t);
-- 
2.9.3

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Alexey Dobriyan]

On Mon, Oct 17, 2016 at 1:01 PM, Adam Borowski <kilobyte@angband.pl> wrote:
> On Mon, Oct 17, 2016 at 05:59:51PM +1100, Nicholas Piggin wrote:
>> On Mon, 17 Oct 2016 08:51:31 +0200
>> Adam Borowski <kilobyte@angband.pl> wrote:

> --- /dev/null
> +++ b/include/asm-generic/asm-prototypes.h
> @@ -0,0 +1,7 @@
> +#include <linux/bitops.h>
> +extern void *__memset(void *, int, __kernel_size_t);
> +extern void *__memcpy(void *, const void *, __kernel_size_t);
> +extern void *__memmove(void *, const void *, __kernel_size_t);
> +extern void *memset(void *, int, __kernel_size_t);
> +extern void *memcpy(void *, const void *, __kernel_size_t);
> +extern void *memmove(void *, const void *, __kernel_size_t);

Before too late, those extern keywords aren't needed and
only slowdown compilation.

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Geert Uytterhoeven]

Hi Alexey,

On Mon, Oct 17, 2016 at 1:12 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Mon, Oct 17, 2016 at 1:01 PM, Adam Borowski <kilobyte@angband.pl> wrote:
>> On Mon, Oct 17, 2016 at 05:59:51PM +1100, Nicholas Piggin wrote:
>>> On Mon, 17 Oct 2016 08:51:31 +0200
>>> Adam Borowski <kilobyte@angband.pl> wrote:
>
>> --- /dev/null
>> +++ b/include/asm-generic/asm-prototypes.h
>> @@ -0,0 +1,7 @@
>> +#include <linux/bitops.h>
>> +extern void *__memset(void *, int, __kernel_size_t);
>> +extern void *__memcpy(void *, const void *, __kernel_size_t);
>> +extern void *__memmove(void *, const void *, __kernel_size_t);
>> +extern void *memset(void *, int, __kernel_size_t);
>> +extern void *memcpy(void *, const void *, __kernel_size_t);
>> +extern void *memmove(void *, const void *, __kernel_size_t);
>
> Before too late, those extern keywords aren't needed and
> only slowdown compilation.

Do you have any profiling data backing this?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Alexey Dobriyan]

On Mon, Oct 17, 2016 at 2:17 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Alexey,
>
> On Mon, Oct 17, 2016 at 1:12 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
>> On Mon, Oct 17, 2016 at 1:01 PM, Adam Borowski <kilobyte@angband.pl> wrote:
>>> On Mon, Oct 17, 2016 at 05:59:51PM +1100, Nicholas Piggin wrote:
>>>> On Mon, 17 Oct 2016 08:51:31 +0200
>>>> Adam Borowski <kilobyte@angband.pl> wrote:
>>
>>> --- /dev/null
>>> +++ b/include/asm-generic/asm-prototypes.h
>>> @@ -0,0 +1,7 @@
>>> +#include <linux/bitops.h>
>>> +extern void *__memset(void *, int, __kernel_size_t);
>>> +extern void *__memcpy(void *, const void *, __kernel_size_t);
>>> +extern void *__memmove(void *, const void *, __kernel_size_t);
>>> +extern void *memset(void *, int, __kernel_size_t);
>>> +extern void *memcpy(void *, const void *, __kernel_size_t);
>>> +extern void *memmove(void *, const void *, __kernel_size_t);
>>
>> Before too late, those extern keywords aren't needed and
>> only slowdown compilation.
>
> Do you have any profiling data backing this?

It is easy to obtain. Here is top 10 with runtime bigger than 0.50%:

_int_malloc
ht_lookup_with_hash
_cpp_lex_direct
cpp_get_token_1
ggc_internal_alloc_statm
_int_free
malloc_consolidate
lex_identifier
enter_macro_context
c_lex_with_flags
bitmap_set_bit
malloc
grokdeclarator
htab_find_slot_with_hash
c_lex_one_token
_cpp_lex_token
pop_scopev
c_parser_declspecs

Imagine you're a compiler. Those extern's are tokens. They need to be parsed
(byte-by-byte), allocated, and, in case of "extern" with prototype, thrown away.
They make line longer forcing people to dance around with splitting
per 80 characters
and generally making everything somewhat slower. Might as well don't new ones.

bitops.h is wrong header as well.
Why do you need bitops for bunch of function prototypes?

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Mathieu OTHACEHE]

> +#include <asm/uaccess.h>
> +#include <asm/uaccess.h>

Included twice.

> +#include <asm/string.h>
> +#include <asm/page.h>
> +#include <asm/checksum.h>
> +
> +#include <asm-generic/asm-prototypes.h>
> +
> +#include <asm/page.h>
> +#include <asm/pgtable.h>
> +#include <asm/special_insns.h>
> +#include <asm/preempt.h>

No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ? 

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Adam Borowski]

On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote:
> > +#include <asm/uaccess.h>
> > +#include <asm/uaccess.h>
> 
> Included twice.

D'oh!

> > +#include <asm/string.h>
> > +#include <asm/page.h>
> > +#include <asm/checksum.h>
> > +
> > +#include <asm-generic/asm-prototypes.h>
> > +
> > +#include <asm/page.h>
> > +#include <asm/pgtable.h>
> > +#include <asm/special_insns.h>
> > +#include <asm/preempt.h>
> 
> No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ? 

diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
new file mode 100644
index 0000000..df13637
--- /dev/null
+++ b/include/asm-generic/asm-prototypes.h
@@ -0,0 +1,7 @@
+#include <linux/bitops.h>

... which has these.

Alexey Dobriyan <adobriyan@gmail.com> wrote:
} bitops.h is wrong header as well.
} Why do you need bitops for bunch of function prototypes?

Unless you guys prefer using low-level headers only, that is.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nicholas Piggin]

Hi Adam,

Thanks, this is looking good. powerpc will be able to use the generic
header.

On Tue, 18 Oct 2016 02:16:26 +0200
Adam Borowski <kilobyte@angband.pl> wrote:

> On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote:
> > > +#include <asm/uaccess.h>
> > > +#include <asm/uaccess.h>  
> > 
> > Included twice.  
> 
> D'oh!
> 
> > > +#include <asm/string.h>
> > > +#include <asm/page.h>
> > > +#include <asm/checksum.h>
> > > +
> > > +#include <asm-generic/asm-prototypes.h>
> > > +
> > > +#include <asm/page.h>
> > > +#include <asm/pgtable.h>
> > > +#include <asm/special_insns.h>
> > > +#include <asm/preempt.h>  
> > 
> > No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ?   
> 
> diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
> new file mode 100644
> index 0000000..df13637
> --- /dev/null
> +++ b/include/asm-generic/asm-prototypes.h
> @@ -0,0 +1,7 @@
> +#include <linux/bitops.h>
> 
> ... which has these.
> 
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
> } bitops.h is wrong header as well.
> } Why do you need bitops for bunch of function prototypes?
> 
> Unless you guys prefer using low-level headers only, that is.

Well you can't use asm/arch_hweight.h in a generic header of course.
I would suggest just including linux/ variants where practical for
the asm-generic/asm-prototypes.h header.

We should probably just bring all these arch patches through the
kbuild tree.

I'm sorry for the breakage: I didn't realize it broke the build with
some configs, otherwise I would have given Michal a heads up before
his pull request, and worked to get this stuff in first.

Thanks,
Nick

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Michal Marek]

Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):
> We should probably just bring all these arch patches through the
> kbuild tree.
> 
> I'm sorry for the breakage: I didn't realize it broke the build with
> some configs, otherwise I would have given Michal a heads up before
> his pull request, and worked to get this stuff in first.

It breaks with some binutils versions only (and only with
CONFIG_MODVERSIONS=y, of course).

Michal

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nicholas Piggin]

On Wed, 19 Oct 2016 16:38:14 +0200
Michal Marek <mmarek@suse.com> wrote:

> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):
> > We should probably just bring all these arch patches through the
> > kbuild tree.
> > 
> > I'm sorry for the breakage: I didn't realize it broke the build with
> > some configs, otherwise I would have given Michal a heads up before
> > his pull request, and worked to get this stuff in first.  
> 
> It breaks with some binutils versions only (and only with
> CONFIG_MODVERSIONS=y, of course).

Yeah this seems to be the issue, it apparently slipped past all the
automated builds. It seems like the existing CRC warnings in the tree
only trigger in rare circumstances too, so something could be a bit
fragile there.

Thanks,
Nick

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Kalle Valo]

(Adding Thorsten because of a serious regression and Steven because he
tried to fix something in the same commit)

Nicholas Piggin <npiggin@gmail.com> writes:

> On Wed, 19 Oct 2016 16:38:14 +0200
> Michal Marek <mmarek@suse.com> wrote:
>
>> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):
>> > We should probably just bring all these arch patches through the
>> > kbuild tree.
>> > 
>> > I'm sorry for the breakage: I didn't realize it broke the build with
>> > some configs, otherwise I would have given Michal a heads up before
>> > his pull request, and worked to get this stuff in first.  
>> 
>> It breaks with some binutils versions only (and only with
>> CONFIG_MODVERSIONS=y, of course).
>
> Yeah this seems to be the issue, it apparently slipped past all the
> automated builds. It seems like the existing CRC warnings in the tree
> only trigger in rare circumstances too, so something could be a bit
> fragile there.

I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
load (log below). After investigating for some time I found this thread
and apparently this is not still fixed, at least not in Linus' tree.

Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
available (please correct me if I'm wrong) we should just revert that
commit until it's properly fixed.

Also note that there's a related fix from Steven:

[PATCH] x86: Fix export for mcount and __fentry__
https://marc.info/?l=linux-kernel&m=147733572502413

For compiling the kernel I'm using Ubuntu 12.04:

ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler

The kernel is running on a separate machine with Ubuntu 14.04.

[  110.703414] bluetooth: disagrees about version of symbol __get_user_2
[  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
[  110.703429] bluetooth: disagrees about version of symbol __put_user_2
[  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
[  110.703579] bluetooth: disagrees about version of symbol __put_user_4
[  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
[  110.703669] bluetooth: disagrees about version of symbol __put_user_1
[  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
[  110.703688] bluetooth: disagrees about version of symbol mcount
[  110.703689] bluetooth: Unknown symbol mcount (err -22)

-- 
Kalle Valo

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nicholas Piggin]

On Thu, 27 Oct 2016 11:10:03 +0300
Kalle Valo <kvalo@codeaurora.org> wrote:

> (Adding Thorsten because of a serious regression and Steven because he
> tried to fix something in the same commit)
> 
> Nicholas Piggin <npiggin@gmail.com> writes:
> 
> > On Wed, 19 Oct 2016 16:38:14 +0200
> > Michal Marek <mmarek@suse.com> wrote:
> >  
> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):  
> >> > We should probably just bring all these arch patches through the
> >> > kbuild tree.
> >> > 
> >> > I'm sorry for the breakage: I didn't realize it broke the build with
> >> > some configs, otherwise I would have given Michal a heads up before
> >> > his pull request, and worked to get this stuff in first.    
> >> 
> >> It breaks with some binutils versions only (and only with
> >> CONFIG_MODVERSIONS=y, of course).  
> >
> > Yeah this seems to be the issue, it apparently slipped past all the
> > automated builds. It seems like the existing CRC warnings in the tree
> > only trigger in rare circumstances too, so something could be a bit
> > fragile there.  
> 
> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
> load (log below). After investigating for some time I found this thread
> and apparently this is not still fixed, at least not in Linus' tree.
> 
> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
> available (please correct me if I'm wrong) we should just revert that
> commit until it's properly fixed.

With these two patches together, does it work for you?

http://marc.info/?l=linux-arch&m=147653546809512&w=2
http://marc.info/?l=linux-kernel&m=147669851906489&w=2

It would be helpful if you could test and let us know, because there seems
to be a very tiny number of configs and toolchains that causes problems.

> 
> Also note that there's a related fix from Steven:
> 
> [PATCH] x86: Fix export for mcount and __fentry__
> https://marc.info/?l=linux-kernel&m=147733572502413
> 
> For compiling the kernel I'm using Ubuntu 12.04:
> 
> ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
> ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler
> 
> The kernel is running on a separate machine with Ubuntu 14.04.
> 
> [  110.703414] bluetooth: disagrees about version of symbol __get_user_2
> [  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
> [  110.703429] bluetooth: disagrees about version of symbol __put_user_2
> [  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
> [  110.703579] bluetooth: disagrees about version of symbol __put_user_4
> [  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
> [  110.703669] bluetooth: disagrees about version of symbol __put_user_1
> [  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
> [  110.703688] bluetooth: disagrees about version of symbol mcount
> [  110.703689] bluetooth: Unknown symbol mcount (err -22)
> 

I haven't seen that one before. Did you definitely make and install new
modules?

Thanks,
Nick

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Kalle Valo]

Nicholas Piggin <npiggin@gmail.com> writes:

> On Thu, 27 Oct 2016 11:10:03 +0300
> Kalle Valo <kvalo@codeaurora.org> wrote:
>
>> (Adding Thorsten because of a serious regression and Steven because he
>> tried to fix something in the same commit)
>> 
>> Nicholas Piggin <npiggin@gmail.com> writes:
>> 
>> > On Wed, 19 Oct 2016 16:38:14 +0200
>> > Michal Marek <mmarek@suse.com> wrote:
>> >  
>> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):  
>> >> > We should probably just bring all these arch patches through the
>> >> > kbuild tree.
>> >> > 
>> >> > I'm sorry for the breakage: I didn't realize it broke the build with
>> >> > some configs, otherwise I would have given Michal a heads up before
>> >> > his pull request, and worked to get this stuff in first.    
>> >> 
>> >> It breaks with some binutils versions only (and only with
>> >> CONFIG_MODVERSIONS=y, of course).  
>> >
>> > Yeah this seems to be the issue, it apparently slipped past all the
>> > automated builds. It seems like the existing CRC warnings in the tree
>> > only trigger in rare circumstances too, so something could be a bit
>> > fragile there.  
>> 
>> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
>> load (log below). After investigating for some time I found this thread
>> and apparently this is not still fixed, at least not in Linus' tree.
>> 
>> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
>> available (please correct me if I'm wrong) we should just revert that
>> commit until it's properly fixed.
>
> With these two patches together, does it work for you?
>
> http://marc.info/?l=linux-arch&m=147653546809512&w=2
> http://marc.info/?l=linux-kernel&m=147669851906489&w=2
>
> It would be helpful if you could test and let us know, because there seems
> to be a very tiny number of configs and toolchains that causes
> problems.

With these two patches (on top of ath-201610251249 from ath.git, in
practice 4.9-rc2 + latest wireless patches) module loading works again.
If you want you can add my Tested-by:

Tested-by: Kalle Valo <kvalo@codeaurora.org>

Can we get these patches to Linus' tree soon? It's annoying to revert
784d5699eddc5 everytime I update my tree.

>> Also note that there's a related fix from Steven:
>> 
>> [PATCH] x86: Fix export for mcount and __fentry__
>> https://marc.info/?l=linux-kernel&m=147733572502413
>> 
>> For compiling the kernel I'm using Ubuntu 12.04:
>> 
>> ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
>> ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler
>> 
>> The kernel is running on a separate machine with Ubuntu 14.04.
>> 
>> [  110.703414] bluetooth: disagrees about version of symbol __get_user_2
>> [  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
>> [  110.703429] bluetooth: disagrees about version of symbol __put_user_2
>> [  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
>> [  110.703579] bluetooth: disagrees about version of symbol __put_user_4
>> [  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
>> [  110.703669] bluetooth: disagrees about version of symbol __put_user_1
>> [  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
>> [  110.703688] bluetooth: disagrees about version of symbol mcount
>> [  110.703689] bluetooth: Unknown symbol mcount (err -22)
>> 
>
> I haven't seen that one before. Did you definitely make and install new
> modules?

I'm pretty sure modules are correctly installed as I have used the same
procedure for years: on my workstation I do 'make bindeb-pkg', copy the
.deb to the test laptop and install the deb there. Also once I revert
784d5699eddc5 it starts immeadiately working.

-- 
Kalle Valo

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nicholas Piggin]

On Thu, 27 Oct 2016 16:14:28 +0300
Kalle Valo <kvalo@codeaurora.org> wrote:

> Nicholas Piggin <npiggin@gmail.com> writes:
> 
> > On Thu, 27 Oct 2016 11:10:03 +0300
> > Kalle Valo <kvalo@codeaurora.org> wrote:
> >  
> >> (Adding Thorsten because of a serious regression and Steven because he
> >> tried to fix something in the same commit)
> >> 
> >> Nicholas Piggin <npiggin@gmail.com> writes:
> >>   
> >> > On Wed, 19 Oct 2016 16:38:14 +0200
> >> > Michal Marek <mmarek@suse.com> wrote:
> >> >    
> >> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):    
> >> >> > We should probably just bring all these arch patches through the
> >> >> > kbuild tree.
> >> >> > 
> >> >> > I'm sorry for the breakage: I didn't realize it broke the build with
> >> >> > some configs, otherwise I would have given Michal a heads up before
> >> >> > his pull request, and worked to get this stuff in first.      
> >> >> 
> >> >> It breaks with some binutils versions only (and only with
> >> >> CONFIG_MODVERSIONS=y, of course).    
> >> >
> >> > Yeah this seems to be the issue, it apparently slipped past all the
> >> > automated builds. It seems like the existing CRC warnings in the tree
> >> > only trigger in rare circumstances too, so something could be a bit
> >> > fragile there.    
> >> 
> >> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
> >> load (log below). After investigating for some time I found this thread
> >> and apparently this is not still fixed, at least not in Linus' tree.
> >> 
> >> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
> >> available (please correct me if I'm wrong) we should just revert that
> >> commit until it's properly fixed.  
> >
> > With these two patches together, does it work for you?
> >
> > http://marc.info/?l=linux-arch&m=147653546809512&w=2
> > http://marc.info/?l=linux-kernel&m=147669851906489&w=2
> >
> > It would be helpful if you could test and let us know, because there seems
> > to be a very tiny number of configs and toolchains that causes
> > problems.  
> 
> With these two patches (on top of ath-201610251249 from ath.git, in
> practice 4.9-rc2 + latest wireless patches) module loading works again.
> If you want you can add my Tested-by:
> 
> Tested-by: Kalle Valo <kvalo@codeaurora.org>

Great, thanks for testing it.

> Can we get these patches to Linus' tree soon? It's annoying to revert
> 784d5699eddc5 everytime I update my tree.

Yes I think it's about ready to merge. Michal is returning from vacation
next week so we should get some progress soon.

> >> Also note that there's a related fix from Steven:
> >> 
> >> [PATCH] x86: Fix export for mcount and __fentry__
> >> https://marc.info/?l=linux-kernel&m=147733572502413
> >> 
> >> For compiling the kernel I'm using Ubuntu 12.04:
> >> 
> >> ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
> >> ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler
> >> 
> >> The kernel is running on a separate machine with Ubuntu 14.04.
> >> 
> >> [  110.703414] bluetooth: disagrees about version of symbol __get_user_2
> >> [  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
> >> [  110.703429] bluetooth: disagrees about version of symbol __put_user_2
> >> [  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
> >> [  110.703579] bluetooth: disagrees about version of symbol __put_user_4
> >> [  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
> >> [  110.703669] bluetooth: disagrees about version of symbol __put_user_1
> >> [  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
> >> [  110.703688] bluetooth: disagrees about version of symbol mcount
> >> [  110.703689] bluetooth: Unknown symbol mcount (err -22)
> >>   
> >
> > I haven't seen that one before. Did you definitely make and install new
> > modules?  
> 
> I'm pretty sure modules are correctly installed as I have used the same
> procedure for years: on my workstation I do 'make bindeb-pkg', copy the
> .deb to the test laptop and install the deb there. Also once I revert
> 784d5699eddc5 it starts immeadiately working.
> 

Sure, I was just checking because I've seen several types of failure but
not this one before. Thanks for reporting and testing.

Thanks,
Nick

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Thorsten Leemhuis]

On 27.10.2016 10:10, Kalle Valo wrote:
> (Adding Thorsten because of a serious regression and Steven because he
> tried to fix something in the same commit)

Many thx.

I added this report to the list of regressions for Linux 4.9. I'll
watch this thread for further updates on this issue to document progress
in my weekly reports. Please let me know via regressions@leemhuis.info
in case the discussion moves to a different place (bugzilla or another
mail thread for example).

Current status (afaics): Fix available, waiting for Michal to get back
from vacation.

tia! Ciao, Thorsten

> Nicholas Piggin <npiggin@gmail.com> writes:
> 
>> On Wed, 19 Oct 2016 16:38:14 +0200
>> Michal Marek <mmarek@suse.com> wrote:
>>
>>> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a):
>>>> We should probably just bring all these arch patches through the
>>>> kbuild tree.
>>>>
>>>> I'm sorry for the breakage: I didn't realize it broke the build with
>>>> some configs, otherwise I would have given Michal a heads up before
>>>> his pull request, and worked to get this stuff in first.  
>>>
>>> It breaks with some binutils versions only (and only with
>>> CONFIG_MODVERSIONS=y, of course).
>>
>> Yeah this seems to be the issue, it apparently slipped past all the
>> automated builds. It seems like the existing CRC warnings in the tree
>> only trigger in rare circumstances too, so something could be a bit
>> fragile there.
> 
> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to
> load (log below). After investigating for some time I found this thread
> and apparently this is not still fixed, at least not in Linus' tree.
> 
> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix
> available (please correct me if I'm wrong) we should just revert that
> commit until it's properly fixed.
> 
> Also note that there's a related fix from Steven:
> 
> [PATCH] x86: Fix export for mcount and __fentry__
> https://marc.info/?l=linux-kernel&m=147733572502413
> 
> For compiling the kernel I'm using Ubuntu 12.04:
> 
> ii  binutils             2.22-6ubuntu1.4      GNU assembler, linker and binary utilities
> ii  gcc                  4:4.6.3-1ubuntu5     GNU C compiler
> 
> The kernel is running on a separate machine with Ubuntu 14.04.
> 
> [  110.703414] bluetooth: disagrees about version of symbol __get_user_2
> [  110.703416] bluetooth: Unknown symbol __get_user_2 (err -22)
> [  110.703429] bluetooth: disagrees about version of symbol __put_user_2
> [  110.703430] bluetooth: Unknown symbol __put_user_2 (err -22)
> [  110.703579] bluetooth: disagrees about version of symbol __put_user_4
> [  110.703580] bluetooth: Unknown symbol __put_user_4 (err -22)
> [  110.703669] bluetooth: disagrees about version of symbol __put_user_1
> [  110.703670] bluetooth: Unknown symbol __put_user_1 (err -22)
> [  110.703688] bluetooth: disagrees about version of symbol mcount
> [  110.703689] bluetooth: Unknown symbol mcount (err -22)
> 

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Michal Marek]

On 2016-10-18 03:34, Nicholas Piggin wrote:
> Hi Adam,
> 
> Thanks, this is looking good. powerpc will be able to use the generic
> header.
> 
> On Tue, 18 Oct 2016 02:16:26 +0200
> Adam Borowski <kilobyte@angband.pl> wrote:
> 
>> On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote:
>>>> +#include <asm/uaccess.h>
>>>> +#include <asm/uaccess.h>  
>>>
>>> Included twice.  
>>
>> D'oh!
>>
>>>> +#include <asm/string.h>
>>>> +#include <asm/page.h>
>>>> +#include <asm/checksum.h>
>>>> +
>>>> +#include <asm-generic/asm-prototypes.h>
>>>> +
>>>> +#include <asm/page.h>
>>>> +#include <asm/pgtable.h>
>>>> +#include <asm/special_insns.h>
>>>> +#include <asm/preempt.h>  
>>>
>>> No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ?   
>>
>> diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
>> new file mode 100644
>> index 0000000..df13637
>> --- /dev/null
>> +++ b/include/asm-generic/asm-prototypes.h
>> @@ -0,0 +1,7 @@
>> +#include <linux/bitops.h>
>>
>> ... which has these.
>>
>> Alexey Dobriyan <adobriyan@gmail.com> wrote:
>> } bitops.h is wrong header as well.
>> } Why do you need bitops for bunch of function prototypes?
>>
>> Unless you guys prefer using low-level headers only, that is.
> 
> Well you can't use asm/arch_hweight.h in a generic header of course.
> I would suggest just including linux/ variants where practical for
> the asm-generic/asm-prototypes.h header.
> 
> We should probably just bring all these arch patches through the
> kbuild tree.

Adam,

are you submitting a new version of your x86 asm-prototypes.h patch?

Thanks,
Michal

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Adam Borowski]

On Tue, Nov 01, 2016 at 04:48:48PM +0100, Michal Marek wrote:
> > Adam Borowski <kilobyte@angband.pl> wrote:
> > 
> >> On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote:
> >>>> +#include <asm/uaccess.h>
> >>>> +#include <asm/uaccess.h>  
> >>>
> >>> Included twice.  
> >>
> >> D'oh!

This appears to be the only thing to fix, right?

> >>>> +#include <asm/string.h>
> >>>> +#include <asm/page.h>
> >>>> +#include <asm/checksum.h>
> >>>> +
> >>>> +#include <asm-generic/asm-prototypes.h>
> >>>> +
> >>>> +#include <asm/page.h>
> >>>> +#include <asm/pgtable.h>
> >>>> +#include <asm/special_insns.h>
> >>>> +#include <asm/preempt.h>  
> >>>
> >>> No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ?   
> >>
> >> diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
> >> new file mode 100644
> >> index 0000000..df13637
> >> --- /dev/null
> >> +++ b/include/asm-generic/asm-prototypes.h
> >> @@ -0,0 +1,7 @@
> >> +#include <linux/bitops.h>
> >>
> >> ... which has these.
> >>
> >> Alexey Dobriyan <adobriyan@gmail.com> wrote:
> >> } bitops.h is wrong header as well.
> >> } Why do you need bitops for bunch of function prototypes?
> >>
> >> Unless you guys prefer using low-level headers only, that is.
> > 
> > Well you can't use asm/arch_hweight.h in a generic header of course.
> > I would suggest just including linux/ variants where practical for
> > the asm-generic/asm-prototypes.h header.
> > 
> > We should probably just bring all these arch patches through the
> > kbuild tree.

I believe inclusion of <linux/bitops.h> is the right thing to do, but if
not, the patch would also need:

extern unsigned int __sw_hweight8(unsigned int w);
extern unsigned int __sw_hweight16(unsigned int w);
extern unsigned int __sw_hweight32(unsigned int w);
extern unsigned long __sw_hweight64(__u64 w);


There's also the issue of mcount/__fentry__, but that's apparently already
dealt with in 5de0a8c, already in mainline.

> are you submitting a new version of your x86 asm-prototypes.h patch?

The update is trivial, but yeah, I can resubmit.  If I'm wrong about where
__sw_hweight{8,16,32,64} should come from, please say so.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Jiri Slaby]

On 10/17/2016, 12:01 PM, Adam Borowski wrote:
> Anyway, here's my stab at x86:

Hi,

what happened to this? I had to apply this to fix 4.9-pae kernel here.

> From db746df65b920591606398b4b244f5b6dc9eea04 Mon Sep 17 00:00:00 2001
> From: Adam Borowski <kilobyte@angband.pl>
> Date: Mon, 17 Oct 2016 11:42:35 +0200
> Subject: [PATCH] kbuild: provide include/asm/asm-prototypes.h for x86
> 
> Nicholas Piggin wrote:
>> Architectures will need to have an include/asm/asm-prototypes.h that
>> defines or #include<>s C-style prototypes for exported asm functions.
>> We can do an asm-generic version for the common ones like memset so
>> there's not a lot of pointless duplication there.
> 
> Signed-off-by: Adam Borowski <kilobyte@angband.pl>
> ---
>  arch/x86/include/asm/asm-prototypes.h | 13 +++++++++++++
>  include/asm-generic/asm-prototypes.h  |  7 +++++++
>  2 files changed, 20 insertions(+)
>  create mode 100644 arch/x86/include/asm/asm-prototypes.h
>  create mode 100644 include/asm-generic/asm-prototypes.h
> 
> diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/asm-prototypes.h
> new file mode 100644
> index 0000000..072c97c
> --- /dev/null
> +++ b/arch/x86/include/asm/asm-prototypes.h
> @@ -0,0 +1,13 @@
> +#include <asm/ftrace.h>
> +#include <asm/uaccess.h>
> +#include <asm/uaccess.h>
> +#include <asm/string.h>
> +#include <asm/page.h>
> +#include <asm/checksum.h>
> +
> +#include <asm-generic/asm-prototypes.h>
> +
> +#include <asm/page.h>
> +#include <asm/pgtable.h>
> +#include <asm/special_insns.h>
> +#include <asm/preempt.h>
> diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h
> new file mode 100644
> index 0000000..df13637
> --- /dev/null
> +++ b/include/asm-generic/asm-prototypes.h
> @@ -0,0 +1,7 @@
> +#include <linux/bitops.h>
> +extern void *__memset(void *, int, __kernel_size_t);
> +extern void *__memcpy(void *, const void *, __kernel_size_t);
> +extern void *__memmove(void *, const void *, __kernel_size_t);
> +extern void *memset(void *, int, __kernel_size_t);
> +extern void *memcpy(void *, const void *, __kernel_size_t);
> +extern void *memmove(void *, const void *, __kernel_size_t);
> 

thanks,
-- 
js
suse labs

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Linus Torvalds]

On Fri, Dec 16, 2016 at 11:55 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>
> what happened to this? I had to apply this to fix 4.9-pae kernel here.

Did you actually have to do that?

Because a missing CRC shouldn't be fatal in 4.9.

What was the failure mode?

                Linus

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Jiri Slaby]

On 12/16/2016, 08:57 PM, Linus Torvalds wrote:
> On Fri, Dec 16, 2016 at 11:55 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>
>> what happened to this? I had to apply this to fix 4.9-pae kernel here.
> 
> Did you actually have to do that?

Yes, disk drivers won't load:
[    2.141973] virtio_pci: disagrees about version of symbol mcount
[    2.144415] virtio_pci: Unknown symbol mcount (err -22)
[    2.164547] virtio_pci: disagrees about version of symbol mcount
[    2.166309] virtio_pci: Unknown symbol mcount (err -22)
[    2.180651] virtio_pci: disagrees about version of symbol mcount
[    2.182823] virtio_pci: Unknown symbol mcount (err -22)
[    2.210943] virtio_pci: disagrees about version of symbol mcount
[    2.220097] virtio_pci: Unknown symbol mcount (err -22)
[    2.220173] ata_piix: disagrees about version of symbol mcount
[    2.220174] ata_piix: Unknown symbol mcount (err -22)

and whole machine gets stuck with systemd waiting for /dev/sd*.

> Because a missing CRC shouldn't be fatal in 4.9.
> 
> What was the failure mode?

I am not sure what you mean? The kernel is rpm-ized 4.9 vanilla and this
is the config:
http://kernel.suse.com/cgit/kernel-source/tree/config/i386/default?h=stable

thanks,
-- 
js
suse labs

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Adam Borowski]

On Sat, Dec 17, 2016 at 09:57:47AM +0100, Jiri Slaby wrote:
> On 12/16/2016, 08:57 PM, Linus Torvalds wrote:
> > On Fri, Dec 16, 2016 at 11:55 AM, Jiri Slaby <jslaby@suse.cz> wrote:
> >>
> >> what happened to this? I had to apply this to fix 4.9-pae kernel here.
> > 
> > Did you actually have to do that?
> 
> Yes, disk drivers won't load:
> [    2.141973] virtio_pci: disagrees about version of symbol mcount
> [    2.144415] virtio_pci: Unknown symbol mcount (err -22)
> and whole machine gets stuck with systemd waiting for /dev/sd*.
> 
> > Because a missing CRC shouldn't be fatal in 4.9.

Most of us get just a scary-looking warning, but whatever the problem is for
you, it's good to hear this patch works around it.

Whatever the long-term solution will be, for 4.10 an updated[1] version of
this fix is on kbuild/kbuild (and kbuild/for-next).  I guess we'll bother
stable@ once it is merged.

Note that it handles only x86, there's a bunch of other architectures
affected, alpha m68k s390 sparc ia64 might still need fixing.


Meow!

[1]. Turns out there was a missing symbol on 486; people build-test those
but don't try to actually boot, and even when they do, they don't read
warnings.
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Linus Torvalds]

On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>
> Yes, disk drivers won't load:
> [    2.141973] virtio_pci: disagrees about version of symbol mcount
> [    2.144415] virtio_pci: Unknown symbol mcount (err -22)

This makes no sense.

mcount isn't even one of the symbols that the patch by Adam is touching.

There's something else screwed up here. Not to mention that others
don't have your issue.

Do you have some other hacks in this area? Are you testing actual
plain 4.9, or do you (for example) still carry Arnd's patch around
that turned out to not work (reverted by f27c2f69cc8e in my tree)?

           Linus

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Jiri Slaby]

On 12/18/2016, 12:59 AM, Linus Torvalds wrote:
> On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>
>> Yes, disk drivers won't load:
>> [    2.141973] virtio_pci: disagrees about version of symbol mcount
>> [    2.144415] virtio_pci: Unknown symbol mcount (err -22)
> 
> This makes no sense.
> 
> mcount isn't even one of the symbols that the patch by Adam is touching.

asm-prototypes.h in his patch includes asm/ftrace.h, where the function
is declared. That should be enough IIUC scripts/Makefile.build.

> There's something else screwed up here. Not to mention that others
> don't have your issue.

I suppose people don't run i386 kernels or have different config.

> Do you have some other hacks in this area? Are you testing actual
> plain 4.9, or do you (for example) still carry Arnd's patch around
> that turned out to not work (reverted by f27c2f69cc8e in my tree)?

Not at all. This was plain 4.9 packaged by suse -- only rpm-related
fixes. I tried plain 4.9 without rpm right now with the same output:
# insmod soundcore.ko
[   31.582326] soundcore: disagrees about version of symbol mcount
[   31.586183] soundcore: Unknown symbol mcount (err -22)
insmod: ERROR: could not insert module soundcore.ko: Invalid parameters


$ git describe @
v4.9
$ git status
HEAD detached at v4.9


thanks,
-- 
js
suse labs

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Arend Van Spriel]

On 18-12-2016 11:49, Jiri Slaby wrote:
> On 12/18/2016, 12:59 AM, Linus Torvalds wrote:
>> On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>>
>>> Yes, disk drivers won't load:
>>> [    2.141973] virtio_pci: disagrees about version of symbol mcount
>>> [    2.144415] virtio_pci: Unknown symbol mcount (err -22)
>>
>> This makes no sense.
>>
>> mcount isn't even one of the symbols that the patch by Adam is touching.
> 
> asm-prototypes.h in his patch includes asm/ftrace.h, where the function
> is declared. That should be enough IIUC scripts/Makefile.build.
> 
>> There's something else screwed up here. Not to mention that others
>> don't have your issue.
> 
> I suppose people don't run i386 kernels or have different config.
> 
>> Do you have some other hacks in this area? Are you testing actual
>> plain 4.9, or do you (for example) still carry Arnd's patch around
>> that turned out to not work (reverted by f27c2f69cc8e in my tree)?
> 
> Not at all. This was plain 4.9 packaged by suse -- only rpm-related
> fixes. I tried plain 4.9 without rpm right now with the same output:
> # insmod soundcore.ko
> [   31.582326] soundcore: disagrees about version of symbol mcount
> [   31.586183] soundcore: Unknown symbol mcount (err -22)
> insmod: ERROR: could not insert module soundcore.ko: Invalid parameters

I hit an mcount issue a while back (years?) which was due to building a
driver with gcc v4.x while kernel was built using gcc v4.y. Not claiming
that is your issue though.

Regards,
Arend

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nikolay Borisov]

On 18.12.2016 13:03, Arend Van Spriel wrote:
> On 18-12-2016 11:49, Jiri Slaby wrote:
>> On 12/18/2016, 12:59 AM, Linus Torvalds wrote:
>>> On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>>>
>>>> Yes, disk drivers won't load:
>>>> [    2.141973] virtio_pci: disagrees about version of symbol mcount
>>>> [    2.144415] virtio_pci: Unknown symbol mcount (err -22)
>>>
>>> This makes no sense.
>>>
>>> mcount isn't even one of the symbols that the patch by Adam is touching.
>>
>> asm-prototypes.h in his patch includes asm/ftrace.h, where the function
>> is declared. That should be enough IIUC scripts/Makefile.build.
>>
>>> There's something else screwed up here. Not to mention that others
>>> don't have your issue.
>>
>> I suppose people don't run i386 kernels or have different config.
>>
>>> Do you have some other hacks in this area? Are you testing actual
>>> plain 4.9, or do you (for example) still carry Arnd's patch around
>>> that turned out to not work (reverted by f27c2f69cc8e in my tree)?
>>
>> Not at all. This was plain 4.9 packaged by suse -- only rpm-related
>> fixes. I tried plain 4.9 without rpm right now with the same output:
>> # insmod soundcore.ko
>> [   31.582326] soundcore: disagrees about version of symbol mcount
>> [   31.586183] soundcore: Unknown symbol mcount (err -22)
>> insmod: ERROR: could not insert module soundcore.ko: Invalid parameters
> 
> I hit an mcount issue a while back (years?) which was due to building a
> driver with gcc v4.x while kernel was built using gcc v4.y. Not claiming
> that is your issue though.

I've usually had the same thing happen to me if things were compiled
with different gcc versions . Essentially in newer gcc (starting with
4.6 I believe) CC_USING_FENTRY is defined, meaning that there is no
mcount() symbol but rather __fentry__. This is the likely problem here.


> 
> Regards,
> Arend
> 

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Jiri Slaby]

On 12/18/2016, 02:27 PM, Nikolay Borisov wrote:
> This is the likely problem here.

No, it is not. How could a rpm be built with two compilers?

Moreover, with some modules, __put_user_1 and others are reported
instead of mcount.

-- 
js
suse labs

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Nikolay Borisov]

On 18.12.2016 16:45, Jiri Slaby wrote:
> Moreover, with some modules, __put_user_1 and others are reported
> instead of mcount.


nm vmlinux | grep __fentry__
nm vmlinux | grep mcount

What do these report ? I bet you that in your vmlinux the first one
would return something like :

ffffffff822f1810 T __fentry__
ffffffff827fdc20 r __kcrctab___fentry__
ffffffff82809461 r __kstrtab___fentry__
ffffffff827e6c20 R __ksymtab___fentry__
 and nothing for the second. Whereas doing nm on the module in question
would give nothing for __fentry__ and something like: U mcount

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Jiri Slaby]

On 12/18/2016, 03:54 PM, Nikolay Borisov wrote:
> 
> 
> On 18.12.2016 16:45, Jiri Slaby wrote:
>> Moreover, with some modules, __put_user_1 and others are reported
>> instead of mcount.
> 
> 
> nm vmlinux | grep __fentry__
> nm vmlinux | grep mcount
> 
> What do these report ? I bet you that in your vmlinux the first one
> would return something like :
> 
> ffffffff822f1810 T __fentry__
> ffffffff827fdc20 r __kcrctab___fentry__
> ffffffff82809461 r __kstrtab___fentry__
> ffffffff827e6c20 R __ksymtab___fentry__
>  and nothing for the second. Whereas doing nm on the module in question
> would give nothing for __fentry__ and something like: U mcount

Well, I have just won a beer:
$ nm vmlinux | grep mcount
         w __crc_mcount
c0b3bd34 r __kcrctab_mcount
c0b41692 r __kstrtab_mcount
c0b2dd04 R __ksymtab_mcount
c0896130 T mcount
c0c9ee20 T __start_mcount_loc
c0cba89c T __stop_mcount_loc
$ nm vmlinux | grep __fentry__
$ nm sound/soundcore.ko | grep mcount
         U mcount

No, I am really not stupid. We compile the kernels like this for over a
decade and it really broke with 4.9. Applying the patch fixes the
problem. Reverting it, makes it recur.

regards,
-- 
js
suse labs