1. 14 Jun, 2018 1 commit
  2. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard...
      b2441318
  3. 20 Apr, 2016 1 commit
  4. 31 Jul, 2015 1 commit
    • Nathan Lynch's avatar
      ARM: 8405/1: VDSO: fix regression with toolchains lacking ld.bfd executable · 3473f265
      Nathan Lynch authored
      The Sourcery CodeBench Lite 2014.05 toolchain (gcc 4.8.3, binutils
      2.24.51) has a GCC which implements -fuse-ld, and it doesn't include
      the gold linker, but it lacks an ld.bfd executable in its
      installation.  This means that passing -fuse-ld=bfd fails with:
      
            VDSO    arch/arm/vdso/vdso.so.raw
          collect2: fatal error: cannot find 'ld'
      
      Arguably this is a deficiency in the toolchain, but I suspect it's
      commonly used enough that it's worth accommodating: just use
      
      cc-ldoption (to cause a link attempt) instead of cc-option to test
      whether we can use -fuse-ld.  So -fuse-ld=bfd won't be used with this
      toolchain, but the build will rightly succeed, just as it does for
      toolchains which don't implement -fuse-ld (and don't use gold as the
      default linker).
      
      Note: this will change the failure mode for a corner case I was trying
      to handle in d2b30cd4
      
      , where the toolchain defaults to the gold
      linker and the BFD linker is not found in PATH, from:
      
            VDSO    arch/arm/vdso/vdso.so.raw
          collect2: fatal error: cannot find 'ld'
      
      i.e. the BFD linker is not found, to:
      
            OBJCOPY arch/arm/vdso/vdso.so
          BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
          linking with -N
      
      that is, we fail to prevent gold from being used as the linker, and it
      produces an object that objcopy can't digest.
      Reported-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Tested-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Tested-by: default avatarRaphaël Poggi <poggi.raph@gmail.com>
      Fixes: d2b30cd4
      
       ("ARM: 8384/1: VDSO: force use of BFD linker")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      3473f265
  5. 06 Jun, 2015 2 commits
    • Nathan Lynch's avatar
      ARM: 8384/1: VDSO: force use of BFD linker · d2b30cd4
      Nathan Lynch authored
      
      
      When using a toolchain with gold as the default linker, the VDSO build
      fails:
      
        VDSO    arch/arm/vdso/vdso.so.raw
        HOSTCC  arch/arm/vdso/vdsomunge
        MUNGE   arch/arm/vdso/vdso.so.dbg
        OBJCOPY arch/arm/vdso/vdso.so
      BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
      linking with -N
      
      For whatever reason, ld.gold is omitting an exidx program header that
      ld.bfd emits, and even when I work around that, I don't get a working
      VDSO.
      
      For now, instead of supporting gold (which will fail to link the
      kernel anyway since it does not implement --pic-veneer), direct the
      compiler to use the traditional bfd linker.  This is accomplished by
      using -fuse-ld, which is implemented in GCC 4.8 and later.
      
      Note: one limitation of this is that if the toolchain is configured
      to use gold by default, and the bfd linker is not in $PATH, the VDSO
      build will fail:
      
        VDSO    arch/arm/vdso/vdso.so.raw
      collect2: fatal error: cannot find 'ld'
      
      This will happen if CROSS_COMPILE begins with a path such as
      /opt/bin/arm-linux-gnu- but /opt/bin is not in $PATH.  This is
      considered an acceptable corner-case limitation and is easily worked
      around.
      
      Additonal note: we use cc-option instead of cc-ldoption so that
      -fuse-ld=bfd is placed in the command line if the compiler recognizes
      the option.  Using cc-ldoption results in an attempt to link, which
      fails in the situation just described, causing -fuse-ld=bfd to be
      omitted and gold to be used for the VDSO link, which is what we're
      trying to prevent.
      Reported-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      d2b30cd4
    • Nathan Lynch's avatar
      ARM: 8385/1: VDSO: group link options · d33ce23b
      Nathan Lynch authored
      
      
      Currently the VDSO's link options are kind of a mess spread between
      
      ccflags-y and cmd_vdsold.  Collect linker directives into one
      variable, VDSO_LDFLAGS, and use that in cmd_vdsold.
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      d33ce23b
  6. 21 Apr, 2015 1 commit
    • Nathan Lynch's avatar
      ARM: 8344/1: VDSO: honor CONFIG_VDSO in Makefile · f80f6531
      Nathan Lynch authored
      
      
      When CONFIG_VDSO=n, the build normally does not enter arch/arm/vdso/
      because arch/arm/Makefile does not add it to core-y.
      
      However, if the user runs 'make arch/arm/vdso/' the VDSO targets will
      get visited.  This is because the VDSO Makefile itself does not
      consider the value of CONFIG_VDSO.
      
      It is arguably better and more consistent behavior to generate an
      empty built-in.o when CONFIG_VDSO=n and the user attempts to build
      arch/arm/vdso/.  It's nicer because it doesn't try to build things
      that Kconfig dependencies are there to prevent (e.g. the dependency on
      AEABI), and it's less confusing than building objects that won't be
      used in the final image.
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      f80f6531
  7. 27 Mar, 2015 1 commit
    • Nathan Lynch's avatar
      ARM: 8330/1: add VDSO user-space code · 8512287a
      Nathan Lynch authored
      
      
      Place VDSO-related user-space code in arch/arm/kernel/vdso/.
      
      It is almost completely written in C with some assembly helpers to
      load the data page address, sample the counter, and fall back to
      system calls when necessary.
      
      The VDSO can service gettimeofday and clock_gettime when
      CONFIG_ARM_ARCH_TIMER is enabled and the architected timer is present
      (and correctly configured).  It reads the CP15-based virtual counter
      to compute high-resolution timestamps.
      
      Of particular note is that a post-processing step ("vdsomunge") is
      necessary to produce a shared object which is architecturally allowed
      to be used by both soft- and hard-float EABI programs.
      
      The 2012 edition of the ARM ABI defines Tag_ABI_VFP_args = 3 "Code is
      compatible with both the base and VFP variants; the user did not
      permit non-variadic functions to pass FP parameters/results."
      Unfortunately current toolchains do not support this tag, which is
      ideally what we would use.
      
      The best available option is to ensure that both EF_ARM_ABI_FLOAT_SOFT
      and EF_ARM_ABI_FLOAT_HARD are unset in the ELF header's e_flags,
      indicating that the shared object is "old" and should be accepted for
      backward compatibility's sake.  While binutils < 2.24 appear to
      produce a vdso.so with both flags clear, 2.24 always sets
      EF_ARM_ABI_FLOAT_SOFT, with no way to inhibit this behavior.  So we
      have to fix things up with a custom post-processing step.
      
      In fact, the VDSO code in glibc does much less validation (including
      checking these flags) than the code for handling conventional
      file-backed shared libraries, so this is a bit moot unless glibc's
      VDSO code becomes more strict.
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      8512287a