An error occurred fetching the project authors.
  1. 29 Sep, 2020 3 commits
    • Will Deacon's avatar
      arm64: Move SSBD prctl() handler alongside other spectre mitigation code · 9e78b659
      Will Deacon authored
      As part of the spectre consolidation effort to shift all of the ghosts
      into their own proton pack, move all of the horrible SSBD prctl() code
      out of its own 'ssbd.c' file.
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      9e78b659
    • Will Deacon's avatar
      arm64: Introduce separate file for spectre mitigations and reporting · 455697ad
      Will Deacon authored
      The spectre mitigation code is spread over a few different files, which
      makes it both hard to follow, but also hard to remove it should we want
      to do that in future.
      
      Introduce a new file for housing the spectre mitigations, and populate
      it with the spectre-v1 reporting code to start with.
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      455697ad
    • Will Deacon's avatar
      arm64: Remove Spectre-related CONFIG_* options · 6e5f0927
      Will Deacon authored
      The spectre mitigations are too configurable for their own good, leading
      to confusing logic trying to figure out when we should mitigate and when
      we shouldn't. Although the plethora of command-line options need to stick
      around for backwards compatibility, the default-on CONFIG options that
      depend on EXPERT can be dropped, as the mitigations only do anything if
      the system is vulnerable, a mitigation is available and the command-line
      hasn't disabled it.
      
      Remove CONFIG_HARDEN_BRANCH_PREDICTOR and CONFIG_ARM64_SSBD in favour of
      enabling this code unconditionally.
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      6e5f0927
  2. 23 Jun, 2020 1 commit
  3. 15 May, 2020 1 commit
  4. 09 Mar, 2020 1 commit
  5. 28 Oct, 2019 1 commit
    • Mark Rutland's avatar
      arm64: entry: convert el1_sync to C · ed3768db
      Mark Rutland authored
      This patch converts the EL1 sync entry assembly logic to C code.
      
      Doing this will allow us to make changes in a slightly more
      readable way. A case in point is supporting kernel-first RAS.
      do_sea() should be called on the CPU that took the fault.
      
      Largely the assembly code is converted to C in a relatively
      straightforward manner.
      
      Since all sync sites share a common asm entry point, the ASM_BUG()
      instances are no longer required for effective backtraces back to
      assembly, and we don't need similar BUG() entries.
      
      The ESR_ELx.EC codes for all (supported) debug exceptions are now
      checked in the el1_sync_handler's switch statement, which renders the
      check in el1_dbg redundant. This both simplifies the el1_dbg handler,
      and makes the EL1 exception handling more robust to
      currently-unallocated ESR_ELx.EC encodings.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      [split out of a bigger series, added nokprobes, moved prototypes]
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      ed3768db
  6. 22 Jun, 2019 1 commit
  7. 23 Apr, 2019 2 commits
  8. 09 Apr, 2019 1 commit
  9. 04 Jan, 2019 1 commit
  10. 13 Dec, 2018 1 commit
  11. 10 Dec, 2018 1 commit
  12. 06 Dec, 2018 2 commits
  13. 11 Sep, 2018 1 commit
  14. 12 Jul, 2018 2 commits
    • Mark Rutland's avatar
      arm64: convert compat wrappers to C · 55f84926
      Mark Rutland authored
      In preparation for converting to pt_regs syscall wrappers, convert our
      existing compat wrappers to C. This will allow the pt_regs wrappers to
      be automatically generated, and will allow for the compat register
      manipulation to be folded in with the pt_regs accesses.
      
      To avoid confusion with the upcoming pt_regs wrappers and existing
      compat wrappers provided by core code, the C wrappers are renamed to
      compat_sys_aarch32_<syscall>.
      
      With the assembly wrappers gone, we can get rid of entry32.S and the
      associated boilerplate.
      
      Note that these must call the ksys_* syscall entry points, as the usual
      sys_* entry points will be modified to take a single pt_regs pointer
      argument.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      55f84926
    • Mark Rutland's avatar
      arm64: convert raw syscall invocation to C · 4141c857
      Mark Rutland authored
      As a first step towards invoking syscalls with a pt_regs argument,
      convert the raw syscall invocation logic to C. We end up with a bit more
      register shuffling, but the unified invocation logic means we can unify
      the tracing paths, too.
      
      Previously, assembly had to open-code calls to ni_sys() when the system
      call number was out-of-bounds for the relevant syscall table. This case
      is now handled by invoke_syscall(), and the assembly no longer need to
      handle this case explicitly. This allows the tracing paths to be
      simplified and unified, as we no longer need the __ni_sys_trace path and
      the __sys_trace_return label.
      
      This only converts the invocation of the syscall. The rest of the
      syscall triage and tracing is left in assembly for now, and will be
      converted in subsequent patches.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      4141c857
  15. 31 May, 2018 1 commit
  16. 11 Apr, 2018 1 commit
  17. 19 Mar, 2018 1 commit
  18. 09 Mar, 2018 1 commit
  19. 13 Jan, 2018 1 commit
    • James Morse's avatar
      arm64: kernel: Add arch-specific SDEI entry code and CPU masking · f5df2696
      James Morse authored
      The Software Delegated Exception Interface (SDEI) is an ARM standard
      for registering callbacks from the platform firmware into the OS.
      This is typically used to implement RAS notifications.
      
      Such notifications enter the kernel at the registered entry-point
      with the register values of the interrupted CPU context. Because this
      is not a CPU exception, it cannot reuse the existing entry code.
      (crucially we don't implicitly know which exception level we interrupted),
      
      Add the entry point to entry.S to set us up for calling into C code. If
      the event interrupted code that had interrupts masked, we always return
      to that location. Otherwise we pretend this was an IRQ, and use SDEI's
      complete_and_resume call to return to vbar_el1 + offset.
      
      This allows the kernel to deliver signals to user space processes. For
      KVM this triggers the world switch, a quick spin round vcpu_run, then
      back into the guest, unless there are pending signals.
      
      Add sdei_mask_local_cpu() calls to the smp_send_stop() code, this covers
      the panic() code-path, which doesn't invoke cpuhotplug notifiers.
      
      Because we can interrupt entry-from/exit-to another EL, we can't trust the
      value in sp_el0 or x29, even if we interrupted the kernel, in this case
      the code in entry.S will save/restore sp_el0 and use the value in
      __entry_task.
      
      When we have VMAP stacks we can interrupt the stack-overflow test, which
      stirs x0 into sp, meaning we have to have our own VMAP stacks. For now
      these are allocated when we probe the interface. Future patches will add
      refcounting hooks to allow the arch code to allocate them lazily.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      f5df2696
  20. 08 Jan, 2018 1 commit
  21. 01 Dec, 2017 1 commit
    • Ard Biesheuvel's avatar
      arm64: ftrace: emit ftrace-mod.o contents through code · be0f272b
      Ard Biesheuvel authored
      When building the arm64 kernel with both CONFIG_ARM64_MODULE_PLTS and
      CONFIG_DYNAMIC_FTRACE enabled, the ftrace-mod.o object file is built
      with the kernel and contains a trampoline that is linked into each
      module, so that modules can be loaded far away from the kernel and
      still reach the ftrace entry point in the core kernel with an ordinary
      relative branch, as is emitted by the compiler instrumentation code
      dynamic ftrace relies on.
      
      In order to be able to build out of tree modules, this object file
      needs to be included into the linux-headers or linux-devel packages,
      which is undesirable, as it makes arm64 a special case (although a
      precedent does exist for 32-bit PPC).
      
      Given that the trampoline essentially consists of a PLT entry, let's
      not bother with a source or object file for it, and simply patch it
      in whenever the trampoline is being populated, using the existing
      PLT support routines.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      be0f272b
  22. 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 license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  23. 02 Oct, 2017 1 commit
    • Masahiro Yamada's avatar
      arm64: remove unneeded copy to init_utsname()->machine · c2f0b54f
      Masahiro Yamada authored
      As you see in init/version.c, init_uts_ns.name.machine is initially
      set to UTS_MACHINE.  There is no point to copy the same string.
      
      I dug the git history to figure out why this line is here.  My best
      guess is like this:
      
       - This line has been around here since the initial support of arm64
         by commit 9703d9d7 ("arm64: Kernel booting and initialisation").
         If ARCH (=arm64) and UTS_MACHINE (=aarch64) do not match,
         arch/$(ARCH)/Makefile is supposed to override UTS_MACHINE, but the
         initial version of arch/arm64/Makefile missed to do that.  Instead,
         the boot code copied "aarch64" to init_utsname()->machine.
      
       - Commit 94ed1f2c ("arm64: setup: report ELF_PLATFORM as the
         machine for utsname") replaced "aarch64" with ELF_PLATFORM to
         make "uname" to reflect the endianness.
      
       - ELF_PLATFORM does not help to provide the UTS machine name to rpm
         target, so commit cfa88c79 ("arm64: Set UTS_MACHINE in the
         Makefile") fixed it.  The commit simply replaced ELF_PLATFORM with
         UTS_MACHINE, but missed the fact the string copy itself is no longer
         needed.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c2f0b54f
  24. 07 Jun, 2017 1 commit
    • Ard Biesheuvel's avatar
      arm64: ftrace: add support for far branches to dynamic ftrace · e71a4e1b
      Ard Biesheuvel authored
      Currently, dynamic ftrace support in the arm64 kernel assumes that all
      core kernel code is within range of ordinary branch instructions that
      occur in module code, which is usually the case, but is no longer
      guaranteed now that we have support for module PLTs and address space
      randomization.
      
      Since on arm64, all patching of branch instructions involves function
      calls to the same entry point [ftrace_caller()], we can emit the modules
      with a trampoline that has unlimited range, and patch both the trampoline
      itself and the branch instruction to redirect the call via the trampoline.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: minor clarification to smp_wmb() comment]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e71a4e1b
  25. 05 Apr, 2017 1 commit
    • AKASHI Takahiro's avatar
      arm64: kdump: provide /proc/vmcore file · e62aaeac
      AKASHI Takahiro authored
      Arch-specific functions are added to allow for implementing a crash dump
      file interface, /proc/vmcore, which can be viewed as a ELF file.
      
      A user space tool, like kexec-tools, is responsible for allocating
      a separate region for the core's ELF header within crash kdump kernel
      memory and filling it in when executing kexec_load().
      
      Then, its location will be advertised to crash dump kernel via a new
      device-tree property, "linux,elfcorehdr", and crash dump kernel preserves
      the region for later use with reserve_elfcorehdr() at boot time.
      
      On crash dump kernel, /proc/vmcore will access the primary kernel's memory
      with copy_oldmem_page(), which feeds the data page-by-page by ioremap'ing
      it since it does not reside in linear mapping on crash dump kernel.
      
      Meanwhile, elfcorehdr_read() is simple as the region is always mapped.
      Signed-off-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      Reviewed-by: default avatarJames Morse <james.morse@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      e62aaeac
  26. 04 Apr, 2017 1 commit
    • Ard Biesheuvel's avatar
      arm64: relocation testing module · 214fad55
      Ard Biesheuvel authored
      This module tests the module loader's ELF relocation processing
      routines. When loaded, it logs output like below.
      
          Relocation test:
          -------------------------------------------------------
          R_AARCH64_ABS64                 0xffff880000cccccc pass
          R_AARCH64_ABS32                 0x00000000f800cccc pass
          R_AARCH64_ABS16                 0x000000000000f8cc pass
          R_AARCH64_MOVW_SABS_Gn          0xffff880000cccccc pass
          R_AARCH64_MOVW_UABS_Gn          0xffff880000cccccc pass
          R_AARCH64_ADR_PREL_LO21         0xffffff9cf4d1a400 pass
          R_AARCH64_PREL64                0xffffff9cf4d1a400 pass
          R_AARCH64_PREL32                0xffffff9cf4d1a400 pass
          R_AARCH64_PREL16                0xffffff9cf4d1a400 pass
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      214fad55
  27. 03 Feb, 2017 1 commit
    • Ard Biesheuvel's avatar
      efi: arm64: Add vmlinux debug link to the Image binary · 757b435a
      Ard Biesheuvel authored
      When building with debugging symbols, take the absolute path to the
      vmlinux binary and add it to the special PE/COFF debug table entry.
      This allows a debug EFI build to find the vmlinux binary, which is
      very helpful in debugging, given that the offset where the Image is
      first loaded by EFI is highly unpredictable.
      
      On implementations of UEFI that choose to implement it, this
      information is exposed via the EFI debug support table, which is a UEFI
      configuration table that is accessible both by the firmware at boot time
      and by the OS at runtime, and lists all PE/COFF images loaded by the
      system.
      
      The format of the NB10 Codeview entry is based on the definition used
      by EDK2, which is our primary reference when it comes to the use of
      PE/COFF in the context of UEFI firmware.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: use realpath instead of shell invocation, as discussed on list]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      757b435a
  28. 31 Aug, 2016 1 commit
  29. 19 Jul, 2016 2 commits
    • Sandeepa Prabhu's avatar
      arm64: Kprobes with single stepping support · 2dd0e8d2
      Sandeepa Prabhu authored
      Add support for basic kernel probes(kprobes) and jump probes
      (jprobes) for ARM64.
      
      Kprobes utilizes software breakpoint and single step debug
      exceptions supported on ARM v8.
      
      A software breakpoint is placed at the probe address to trap the
      kernel execution into the kprobe handler.
      
      ARM v8 supports enabling single stepping before the break exception
      return (ERET), with next PC in exception return address (ELR_EL1). The
      kprobe handler prepares an executable memory slot for out-of-line
      execution with a copy of the original instruction being probed, and
      enables single stepping. The PC is set to the out-of-line slot address
      before the ERET. With this scheme, the instruction is executed with the
      exact same register context except for the PC (and DAIF) registers.
      
      Debug mask (PSTATE.D) is enabled only when single stepping a recursive
      kprobe, e.g.: during kprobes reenter so that probed instruction can be
      single stepped within the kprobe handler -exception- context.
      The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
      any further re-entry is prevented by not calling handlers and the case
      counted as a missed kprobe).
      
      Single stepping from the x-o-l slot has a drawback for PC-relative accesses
      like branching and symbolic literals access as the offset from the new PC
      (slot address) may not be ensured to fit in the immediate value of
      the opcode. Such instructions need simulation, so reject
      probing them.
      
      Instructions generating exceptions or cpu mode change are rejected
      for probing.
      
      Exclusive load/store instructions are rejected too.  Additionally, the
      code is checked to see if it is inside an exclusive load/store sequence
      (code from Pratyush).
      
      System instructions are mostly enabled for stepping, except MSR/MRS
      accesses to "DAIF" flags in PSTATE, which are not safe for
      probing.
      
      This also changes arch/arm64/include/asm/ptrace.h to use
      include/asm-generic/ptrace.h.
      
      Thanks to Steve Capper and Pratyush Anand for several suggested
      Changes.
      Signed-off-by: default avatarSandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
      Signed-off-by: default avatarDavid A. Long <dave.long@linaro.org>
      Signed-off-by: default avatarPratyush Anand <panand@redhat.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      2dd0e8d2
    • David A. Long's avatar
      arm64: add conditional instruction simulation support · 2af3ec08
      David A. Long authored
      Cease using the arm32 arm_check_condition() function and replace it with
      a local version for use in deprecated instruction support on arm64. Also
      make the function table used by this available for future use by kprobes
      and/or uprobes.
      
      This function is derived from code written by Sandeepa Prabhu.
      Signed-off-by: default avatarSandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
      Signed-off-by: default avatarDavid A. Long <dave.long@linaro.org>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      2af3ec08
  30. 11 Jul, 2016 2 commits
    • Kevin Brodsky's avatar
      arm64: fix vdso-offsets.h dependency · a66649da
      Kevin Brodsky authored
      arm64/kernel/{vdso,signal}.c include vdso-offsets.h, as well as any
      file that includes asm/vdso.h. Therefore, vdso-offsets.h must be
      generated before these files are compiled.
      
      The current rules in arm64/kernel/Makefile do not actually enforce
      this, because even though $(obj)/vdso is listed as a prerequisite for
      vdso-offsets.h, this does not result in the intended effect of
      building the vdso subdirectory (before all the other objects). As a
      consequence, depending on the order in which the rules are followed,
      vdso-offsets.h is updated or not before arm64/kernel/{vdso,signal}.o
      are built. The current rules also impose an unnecessary dependency on
      vdso-offsets.h for all arm64/kernel/*.o, resulting in unnecessary
      rebuilds. This is made obvious when using make -j:
      
        touch arch/arm64/kernel/vdso/gettimeofday.S && make -j$NCPUS arch/arm64/kernel
      
      will sometimes result in none of arm64/kernel/*.o being
      rebuilt, sometimes all of them, or even just some of them.
      
      It is quite difficult to ensure that a header is generated before it
      is used with recursive Makefiles by using normal rules.  Instead,
      arch-specific generated headers are normally built in the archprepare
      recipe in the arch Makefile (see for instance arch/ia64/Makefile).
      Unfortunately, asm-offsets.h is included in gettimeofday.S, and must
      therefore be generated before vdso-offsets.h, which is not the case if
      archprepare is used. For this reason, a rule run after archprepare has
      to be used.
      
      This commit adds rules in arm64/Makefile to build vdso-offsets.h
      during the prepare step, ensuring that vdso-offsets.h is generated
      before building anything. It also removes the now-unnecessary
      dependencies on vdso-offsets.h in arm64/kernel/Makefile. Finally, it
      removes the duplication of asm-offsets.h between arm64/kernel/vdso/
      and include/generated/ and makes include/generated/vdso-offsets.h a
      target in arm64/kernel/vdso/Makefile.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Michal Marek <mmarek@suse.com>
      Signed-off-by: default avatarKevin Brodsky <kevin.brodsky@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      a66649da
    • Catalin Marinas's avatar
      Revert "arm64: Fix vdso-offsets.h dependency" · 7d9a7086
      Catalin Marinas authored
      This reverts commit 90f777be.
      
      While this commit was aimed at fixing the dependencies, with a large
      make -j the vdso-offsets.h file is not generated, leading to build
      failures.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      7d9a7086
  31. 08 Jul, 2016 1 commit
    • Catalin Marinas's avatar
      arm64: Fix vdso-offsets.h dependency · 90f777be
      Catalin Marinas authored
      arch/arm64/kernel/{vdso,signal}.c include generated/vdso-offsets.h, and
      therefore the symbol offsets must be generated before these files are
      compiled.
      
      The current rules in arm64/kernel/Makefile do not actually enforce
      this, because even though $(obj)/vdso is listed as a prerequisite for
      vdso-offsets.h, this does not result in the intended effect of
      building the vdso subdirectory (before all the other objects). As a
      consequence, depending on the order in which the rules are followed,
      vdso-offsets.h is updated or not before arm64/kernel/{vdso,signal}.o
      are built. The current rules also impose an unnecessary dependency on
      vdso-offsets.h for all arm64/kernel/*.o, resulting in unnecessary
      rebuilds.
      
      This patch removes the arch/arm64/kernel/vdso/vdso-offsets.h file
      generation, leaving only the include/generated/vdso-offsets.h one. It
      adds a forced dependency check of the vdso-offsets.h file in
      arch/arm64/kernel/Makefile which, if not up to date according to the
      arch/arm64/kernel/vdso/Makefile rules (depending on vdso.so.dbg), will
      trigger the vdso/ subdirectory build and vdso-offsets.h re-generation.
      Automatic kbuild dependency rules between kernel/{vdso,signal}.c rules
      and vdso-offsets.h will guarantee that the vDSO object is built first,
      followed by the generated symbol offsets header file.
      Reported-by: default avatarKevin Brodsky <kevin.brodsky@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      90f777be
  32. 27 Jun, 2016 1 commit
  33. 30 May, 2016 1 commit