1. 26 Apr, 2017 1 commit
    • Ard Biesheuvel's avatar
      arm64: module: split core and init PLT sections · 24af6c4e
      Ard Biesheuvel authored
      The arm64 module PLT code allocates all PLT entries in a single core
      section, since the overhead of having a separate init PLT section is
      not justified by the small number of PLT entries usually required for
      init code.
      
      However, the core and init module regions are allocated independently,
      and there is a corner case where the core region may be allocated from
      the VMALLOC region if the dedicated module region is exhausted, but the
      init region, being much smaller, can still be allocated from the module
      region. This leads to relocation failures if the distance between those
      regions exceeds 128 MB. (In fact, this corner case is highly unlikely to
      occur on arm64, but the issue has been observed on ARM, whose module
      region is much smaller).
      
      So split the core and init PLT regions, and name the latter ".init.plt"
      so it gets allocated along with (and sufficiently close to) the .init
      sections that it serves. Also, given that init PLT entries may need to
      be emitted for branches that target the core module, modify the logic
      that disregards defined symbols to only disregard symbols that are
      defined in the same section as the relocated branch instruction.
      
      Since there may now be two PLT entries associated with each entry in
      the symbol table, we can no longer hijack the symbol::st_size fields
      to record the addresses of PLT entries as we emit them for zero-addend
      relocations. So instead, perform an explicit comparison to check for
      duplicate entries.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      24af6c4e
  2. 25 Apr, 2017 1 commit
  3. 24 Apr, 2017 1 commit
  4. 12 Apr, 2017 2 commits
    • Catalin Marinas's avatar
      Merge branch 'will/for-next/perf' into for-next/core · 494bc3cd
      Catalin Marinas authored
      * will/for-next/perf:
        arm64: pmuv3: use arm_pmu ACPI framework
        arm64: pmuv3: handle !PMUv3 when probing
        drivers/perf: arm_pmu: add ACPI framework
        arm64: add function to get a cpu's MADT GICC table
        drivers/perf: arm_pmu: split out platform device probe logic
        drivers/perf: arm_pmu: move irq request/free into probe
        drivers/perf: arm_pmu: split cpu-local irq request/free
        drivers/perf: arm_pmu: rename irq request/free functions
        drivers/perf: arm_pmu: handle no platform_device
        drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs()
        drivers/perf: arm_pmu: factor out pmu registration
        drivers/perf: arm_pmu: fold init into alloc
        drivers/perf: arm_pmu: define armpmu_init_fn
        drivers/perf: arm_pmu: remove pointless PMU disabling
        perf: qcom: Add L3 cache PMU driver
        drivers/perf: arm_pmu: split irq request from enable
        drivers/perf: arm_pmu: manage interrupts per-cpu
        drivers/perf: arm_pmu: rework per-cpu allocation
        MAINTAINERS: Add file patterns for perf device tree bindings
      494bc3cd
    • Marc Zyngier's avatar
      arm64: Silence spurious kbuild warning on menuconfig · d91750f1
      Marc Zyngier authored
      Since bbb56c27 ("arm64: Add detection code for broken .inst support
      in binutils"), running any make target that doesn't involve the cross
      compiler results in a spurious warning:
      
      $ make ARCH=arm64 menuconfig
      arch/arm64/Makefile:43: Detected assembler with broken .inst; disassembly will be unreliable
      
      while
      
      $ make ARCH=arm64 CROSS_COMPILE=aarch64-arm-linux- menuconfig
      
      is silent (assuming your compiler is not affected). That's because
      the code that tests for the workaround is always run, irrespective
      of the current configuration being available or not.
      
      An easy fix is to make the detection conditional on CONFIG_ARM64
      being defined, which is only the case when actually building
      something.
      
      Fixes: bbb56c27 ("arm64: Add detection code for broken .inst support in binutils")
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      d91750f1
  5. 11 Apr, 2017 14 commits
  6. 07 Apr, 2017 6 commits
  7. 06 Apr, 2017 1 commit
    • Stephen Boyd's avatar
      arm64: print a fault message when attempting to write RO memory · b824b930
      Stephen Boyd authored
      If a page is marked read only we should print out that fact,
      instead of printing out that there was a page fault. Right now we
      get a cryptic error message that something went wrong with an
      unhandled fault, but we don't evaluate the esr to figure out that
      it was a read/write permission fault.
      
      Instead of seeing:
      
        Unable to handle kernel paging request at virtual address ffff000008e460d8
        pgd = ffff800003504000
        [ffff000008e460d8] *pgd=0000000083473003, *pud=0000000083503003, *pmd=0000000000000000
        Internal error: Oops: 9600004f [#1] PREEMPT SMP
      
      we'll see:
      
        Unable to handle kernel write to read-only memory at virtual address ffff000008e760d8
        pgd = ffff80003d3de000
        [ffff000008e760d8] *pgd=0000000083472003, *pud=0000000083435003, *pmd=0000000000000000
        Internal error: Oops: 9600004f [#1] PREEMPT SMP
      
      We also add a userspace address check into is_permission_fault()
      so that the function doesn't return true for ttbr0 PAN faults
      when it shouldn't.
      Reviewed-by: default avatarJames Morse <james.morse@arm.com>
      Tested-by: default avatarJames Morse <james.morse@arm.com>
      Acked-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarStephen Boyd <stephen.boyd@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      b824b930
  8. 05 Apr, 2017 14 commits