1. 03 Jan, 2019 3 commits
  2. 14 Dec, 2018 1 commit
    • Miles Chen's avatar
      arm64: kaslr: print PHYS_OFFSET in dump_kernel_offset() · 12f799c8
      Miles Chen authored
      When debug with kaslr, it is sometimes necessary to have PHYS_OFFSET to
      perform linear virtual address to physical address translation.
      Sometimes we're debugging with only few information such as a kernel log
      and a symbol file, print PHYS_OFFSET in dump_kernel_offset() for that case.
      Tested by:
      echo c > /proc/sysrq-trigger
      [   11.996161] SMP: stopping secondary CPUs
      [   11.996732] Kernel Offset: 0x2522200000 from 0xffffff8008000000
      [   11.996881] PHYS_OFFSET: 0xffffffeb40000000
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMiles Chen <miles.chen@mediatek.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  3. 13 Dec, 2018 18 commits
  4. 12 Dec, 2018 6 commits
    • Will Deacon's avatar
      Merge branch 'for-next/perf' into aarch64/for-next/core · b47f515b
      Will Deacon authored
      Merge in arm64 perf and PMU driver updates, including support for the
      system/uncore PMU in the ThunderX2 platform.
    • Ard Biesheuvel's avatar
      arm64: enable per-task stack canaries · 0a1213fa
      Ard Biesheuvel authored
      This enables the use of per-task stack canary values if GCC has
      support for emitting the stack canary reference relative to the
      value of sp_el0, which holds the task struct pointer in the arm64
      The $(eval) extends KBUILD_CFLAGS at the moment the make rule is
      applied, which means asm-offsets.o (which we rely on for the offset
      value) is built without the arguments, and everything built afterwards
      has the options set.
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Robin Murphy's avatar
      arm64: Add memory hotplug support · 4ab21506
      Robin Murphy authored
      Wire up the basic support for hot-adding memory. Since memory hotplug
      is fairly tightly coupled to sparsemem, we tweak pfn_valid() to also
      cross-check the presence of a section in the manner of the generic
      implementation, before falling back to memblock to check for no-map
      regions within a present section as before. By having arch_add_memory(()
      create the linear mapping first, this then makes everything work in the
      way that __add_section() expects.
      We expect hotplug to be ACPI-driven, so the swapper_pg_dir updates
      should be safe from races by virtue of the global device hotplug lock.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Will Deacon's avatar
      arm64: percpu: Fix LSE implementation of value-returning pcpu atomics · 6e4ede69
      Will Deacon authored
      Commit 959bf2fd ("arm64: percpu: Rewrite per-cpu ops to allow use of
      LSE atomics") introduced alternative code sequences for the arm64 percpu
      atomics, so that the LSE instructions can be patched in at runtime if
      they are supported by the CPU.
      Unfortunately, when patching in the LSE sequence for a value-returning
      pcpu atomic, the argument registers are the wrong way round. The
      implementation of this_cpu_add_return() therefore ends up adding
      uninitialised stack to the percpu variable and returning garbage.
      As it turns out, there aren't very many users of the value-returning
      percpu atomics in mainline and we only spotted this due to a failure in
      the kprobes selftests. In this case, when attempting to single-step over
      the out-of-line instruction slot, the debug monitors would not be
      enabled because calling this_cpu_inc_return() on the kernel debug
      monitor refcount would fail to detect the transition from 0. We would
      consequently execute past the slot and take an undefined instruction
      exception from the kernel, resulting in a BUG:
       | kernel BUG at arch/arm64/kernel/traps.c:421!
       | PREEMPT SMP
       | pc : do_undefinstr+0x268/0x278
       | lr : do_undefinstr+0x124/0x278
       | Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
       | Call trace:
       |  do_undefinstr+0x268/0x278
       |  el1_undef+0x10/0x78
       |  0xffff00000803c004
       |  init_kprobes+0x150/0x180
       |  do_one_initcall+0x74/0x178
       |  kernel_init_freeable+0x188/0x224
       |  kernel_init+0x10/0x100
       |  ret_from_fork+0x10/0x1c
      Fix the argument order to get the value-returning pcpu atomics working
      correctly when implemented using the LSE instructions.
      Reported-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Mark Rutland's avatar
      arm64: add <asm/asm-prototypes.h> · c3296a13
      Mark Rutland authored
      While we can export symbols from assembly files, CONFIG_MODVERIONS requires C
      declarations of anyhting that's exported.
      Let's account for this as other architectures do by placing these declarations
      in <asm/asm-prototypes.h>, which kbuild will automatically use to generate
      modversion information for assembly files.
      Since we already define most prototypes in existing headers, we simply need to
      include those headers in <asm/asm-prototypes.h>, and don't need to duplicate
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Will Deacon's avatar
      arm64: mm: Introduce MAX_USER_VA_BITS definition · 9b31cf49
      Will Deacon authored
      With the introduction of 52-bit virtual addressing for userspace, we are
      now in a position where the virtual addressing capability of userspace
      may exceed that of the kernel. Consequently, the VA_BITS definition
      cannot be used blindly, since it reflects only the size of kernel
      virtual addresses.
      This patch introduces MAX_USER_VA_BITS which is either VA_BITS or 52
      depending on whether 52-bit virtual addressing has been configured at
      build time, removing a few places where the 52 is open-coded based on
      explicit CONFIG_ guards.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  5. 11 Dec, 2018 3 commits
    • Arnd Bergmann's avatar
      arm64: fix ARM64_USER_VA_BITS_52 builds · 4d08d20f
      Arnd Bergmann authored
      In some randconfig builds, the new CONFIG_ARM64_USER_VA_BITS_52
      triggered a build failure:
      arch/arm64/mm/proc.S:287: Error: immediate out of range
      As it turns out, we were incorrectly setting PGTABLE_LEVELS here,
      lacking any other default value.
      This fixes the calculation of CONFIG_PGTABLE_LEVELS to consider
      all combinations again.
      Fixes: 68d23da4 ("arm64: Kconfig: Re-jig CONFIG options for 52-bit VA")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Will Deacon's avatar
      arm64: preempt: Fix big-endian when checking preempt count in assembly · 7faa313f
      Will Deacon authored
      Commit 39624469 ("arm64: preempt: Provide our own implementation of
      asm/preempt.h") extended the preempt count field in struct thread_info
      to 64 bits, so that it consists of a 32-bit count plus a 32-bit flag
      indicating whether or not the current task needs rescheduling.
      Whilst the asm-offsets definition of TSK_TI_PREEMPT was updated to point
      to this new field, the assembly usage was left untouched meaning that a
      32-bit load from TSK_TI_PREEMPT on a big-endian machine actually returns
      the reschedule flag instead of the count.
      Whilst we could fix this by pointing TSK_TI_PREEMPT at the count field,
      we're actually better off reworking the two assembly users so that they
      operate on the whole 64-bit value in favour of inspecting the thread
      flags separately in order to determine whether a reschedule is needed.
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reported-by: default avatar"kernelci.org bot" <bot@kernelci.org>
      Tested-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Arnd Bergmann's avatar
      arm64: kexec_file: include linux/vmalloc.h · 732291c4
      Arnd Bergmann authored
      This is needed for compilation in some configurations that don't
      include it implicitly:
      arch/arm64/kernel/machine_kexec_file.c: In function 'arch_kimage_file_post_load_cleanup':
      arch/arm64/kernel/machine_kexec_file.c:37:2: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
      Fixes: 52b2a8af ("arm64: kexec_file: load initrd and device-tree")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  6. 10 Dec, 2018 9 commits
    • Will Deacon's avatar
      arm64: mm: EXPORT vabits_user to modules · 4a1daf29
      Will Deacon authored
      TASK_SIZE is defined using the vabits_user variable for 64-bit tasks,
      so ensure that this variable is exported to modules to avoid the
      following build breakage with allmodconfig:
       | ERROR: "vabits_user" [lib/test_user_copy.ko] undefined!
       | ERROR: "vabits_user" [drivers/misc/lkdtm/lkdtm.ko] undefined!
       | ERROR: "vabits_user" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined!
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Will Deacon's avatar
      Merge branch 'for-next/kexec' into aarch64/for-next/core · d34664f6
      Will Deacon authored
      Merge in kexec_file_load() support from Akashi Takahiro.
    • Will Deacon's avatar
      Merge branch 'kvm/cortex-a76-erratum-1165522' into aarch64/for-next/core · bc84a2d1
      Will Deacon authored
      Pull in KVM workaround for A76 erratum #116522.
    • Suzuki K Poulose's avatar
      arm64: smp: Handle errors reported by the firmware · f357b3a7
      Suzuki K Poulose authored
      The __cpu_up() routine ignores the errors reported by the firmware
      for a CPU bringup operation and looks for the error status set by the
      booting CPU. If the CPU never entered the kernel, we could end up
      in assuming stale error status, which otherwise would have been
      set/cleared appropriately by the booting CPU.
      Reported-by: default avatarSteve Capper <steve.capper@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Will Deacon's avatar
      arm64: smp: Rework early feature mismatched detection · 66f16a24
      Will Deacon authored
      Rather than add additional variables to detect specific early feature
      mismatches with secondary CPUs, we can instead dedicate the upper bits
      of the CPU boot status word to flag specific mismatches.
      This allows us to communicate both granule and VA-size mismatches back
      to the primary CPU without the need for additional book-keeping.
      Tested-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Will Deacon's avatar
      arm64: Kconfig: Re-jig CONFIG options for 52-bit VA · 68d23da4
      Will Deacon authored
      Enabling 52-bit VAs for userspace is pretty confusing, since it requires
      you to select "48-bit" virtual addressing in the Kconfig.
      Rework the logic so that 52-bit user virtual addressing is advertised in
      the "Virtual address space size" choice, along with some help text to
      describe its interaction with Pointer Authentication. The EXPERT-only
      option to force all user mappings to the 52-bit range is then made
      available immediately below the VA size selection.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Steve Capper's avatar
      arm64: mm: Allow forcing all userspace addresses to 52-bit · b9567720
      Steve Capper authored
      On arm64 52-bit VAs are provided to userspace when a hint is supplied to
      mmap. This helps maintain compatibility with software that expects at
      most 48-bit VAs to be returned.
      In order to help identify software that has 48-bit VA assumptions, this
      patch allows one to compile a kernel where 52-bit VAs are returned by
      default on HW that supports it.
      This feature is intended to be for development systems only.
      Signed-off-by: default avatarSteve Capper <steve.capper@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Steve Capper's avatar
      arm64: mm: introduce 52-bit userspace support · 67e7fdfc
      Steve Capper authored
      On arm64 there is optional support for a 52-bit virtual address space.
      To exploit this one has to be running with a 64KB page size and be
      running on hardware that supports this.
      For an arm64 kernel supporting a 48 bit VA with a 64KB page size,
      some changes are needed to support a 52-bit userspace:
       * TCR_EL1.T0SZ needs to be 12 instead of 16,
       * TASK_SIZE needs to reflect the new size.
      This patch implements the above when the support for 52-bit VAs is
      detected at early boot time.
      On arm64 userspace addresses translation is controlled by TTBR0_EL1. As
      well as userspace, TTBR0_EL1 controls:
       * The identity mapping,
       * EFI runtime code.
      It is possible to run a kernel with an identity mapping that has a
      larger VA size than userspace (and for this case __cpu_set_tcr_t0sz()
      would set TCR_EL1.T0SZ as appropriate). However, when the conditions for
      52-bit userspace are met; it is possible to keep TCR_EL1.T0SZ fixed at
      12. Thus in this patch, the TCR_EL1.T0SZ size changing logic is
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Steve Capper's avatar
      arm64: mm: Prevent mismatched 52-bit VA support · a96a33b1
      Steve Capper authored
      For cases where there is a mismatch in ARMv8.2-LVA support between CPUs
      we have to be careful in allowing secondary CPUs to boot if 52-bit
      virtual addresses have already been enabled on the boot CPU.
      This patch adds code to the secondary startup path. If the boot CPU has
      enabled 52-bit VAs then ID_AA64MMFR2_EL1 is checked to see if the
      secondary can also enable 52-bit support. If not, the secondary is
      prevented from booting and an error message is displayed indicating why.
      Technically this patch could be implemented using the cpufeature code
      when considering 52-bit userspace support. However, we employ low level
      checks here as the cpufeature code won't be able to run if we have
      mismatched 52-bit kernel va support.
      Signed-off-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>