1. 29 Jul, 2016 1 commit
    • Ard Biesheuvel's avatar
      arm64: vmlinux.lds: make __rela_offset and __dynsym_offset ABSOLUTE · d6732fc4
      Ard Biesheuvel authored
      Due to the untyped KIMAGE_VADDR constant, the linker may not notice
      that the __rela_offset and __dynsym_offset expressions are absolute
      values (i.e., are not subject to relocation). This does not matter for
      KASLR, but it does confuse kallsyms in relative mode, since it uses
      the lowest non-absolute symbol address as the anchor point, and expects
      all other symbol addresses to be within 4 GB of it.
      
      Fix this by qualifying these expressions as ABSOLUTE() explicitly.
      
      Fixes: 0cd3defe ("arm64: kernel: perform relocation processing from ID map")
      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>
      d6732fc4
  2. 27 Jul, 2016 1 commit
  3. 26 Jul, 2016 1 commit
  4. 25 Jul, 2016 2 commits
  5. 21 Jul, 2016 5 commits
    • Catalin Marinas's avatar
      Merge branch 'for-next/kprobes' into for-next/core · a95b0644
      Catalin Marinas authored
      * kprobes:
        arm64: kprobes: Add KASAN instrumentation around stack accesses
        arm64: kprobes: Cleanup jprobe_return
        arm64: kprobes: Fix overflow when saving stack
        arm64: kprobes: WARN if attempting to step with PSTATE.D=1
        kprobes: Add arm64 case in kprobe example module
        arm64: Add kernel return probes support (kretprobes)
        arm64: Add trampoline code for kretprobes
        arm64: kprobes instruction simulation support
        arm64: Treat all entry code as non-kprobe-able
        arm64: Blacklist non-kprobe-able symbol
        arm64: Kprobes with single stepping support
        arm64: add conditional instruction simulation support
        arm64: Add more test functions to insn.c
        arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
      a95b0644
    • Suzuki K Poulose's avatar
      arm64: Honor nosmp kernel command line option · e75118a7
      Suzuki K Poulose authored
      Passing "nosmp" should boot the kernel with a single processor, without
      provision to enable secondary CPUs even if they are present. "nosmp" is
      implemented by setting maxcpus=0. At the moment we still mark the secondary
      CPUs present even with nosmp, which allows the userspace to bring them
      up. This patch corrects the smp_prepare_cpus() to honor the maxcpus == 0.
      
      Commit 44dbcc93 ("arm64: Fix behavior of maxcpus=N") fixed the
      behavior for maxcpus >= 1, but broke maxcpus = 0.
      
      Fixes: 44dbcc93 ("arm64: Fix behavior of maxcpus=N")
      Cc: <stable@vger.kernel.org> # 4.7+
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      [catalin.marinas@arm.com: updated code comment]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      e75118a7
    • Suzuki K Poulose's avatar
      arm64: Fix incorrect per-cpu usage for boot CPU · 9113c2aa
      Suzuki K Poulose authored
      In smp_prepare_boot_cpu(), we invoke cpuinfo_store_boot_cpu to  store
      the cpuinfo in a per-cpu ptr, before initialising the per-cpu offset for
      the boot CPU. This patch reorders the sequence to make sure we initialise
      the per-cpu offset before accessing the per-cpu area.
      
      Commit 4b998ff1 ("arm64: Delay cpuinfo_store_boot_cpu") fixed the
      issue where we modified the per-cpu area even before the kernel initialises
      the per-cpu areas, but failed to wait until the boot cpu updated it's
      offset.
      
      Fixes: 4b998ff1 ("arm64: Delay cpuinfo_store_boot_cpu")
      Cc: <stable@vger.kernel.org> # 4.4+
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      9113c2aa
    • Catalin Marinas's avatar
      arm64: kprobes: Add KASAN instrumentation around stack accesses · f7e35c5b
      Catalin Marinas authored
      This patch disables KASAN around the memcpy from/to the kernel or IRQ
      stacks to avoid warnings like below:
      
      BUG: KASAN: stack-out-of-bounds in setjmp_pre_handler+0xe4/0x170 at addr ffff800935cbbbc0
      Read of size 128 by task swapper/0/1
      page:ffff7e0024d72ec0 count:0 mapcount:0 mapping:          (null) index:0x0
      flags: 0x1000000000000000()
      page dumped because: kasan: bad access detected
      CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc4+ #1
      Hardware name: ARM Juno development board (r0) (DT)
      Call trace:
      [<ffff20000808ad88>] dump_backtrace+0x0/0x280
      [<ffff20000808b01c>] show_stack+0x14/0x20
      [<ffff200008563a64>] dump_stack+0xa4/0xc8
      [<ffff20000824a1fc>] kasan_report_error+0x4fc/0x528
      [<ffff20000824a5e8>] kasan_report+0x40/0x48
      [<ffff20000824948c>] check_memory_region+0x144/0x1a0
      [<ffff200008249814>] memcpy+0x34/0x68
      [<ffff200008c3ee2c>] setjmp_pre_handler+0xe4/0x170
      [<ffff200008c3ec5c>] kprobe_breakpoint_handler+0xec/0x1d8
      [<ffff2000080853a4>] brk_handler+0x5c/0xa0
      [<ffff2000080813f0>] do_debug_exception+0xa0/0x138
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      f7e35c5b
    • Marc Zyngier's avatar
      arm64: kprobes: Cleanup jprobe_return · 3b7d14e9
      Marc Zyngier authored
      jprobe_return seems to have aged badly. Comments referring to
      non-existent behaviours, and a dangerous habit of messing
      with registers without telling the compiler.
      
      This patches applies the following remedies:
      - Fix the comments to describe the actual behaviour
      - Tidy up the asm sequence to directly assign the
        stack pointer without clobbering extra registers
      - Mark the rest of the function as unreachable() so
        that the compiler knows that there is no need for
        an epilogue
      - Stop making jprobe_return_break a global function
        (you really don't want to call that guy, and it isn't
        even a function).
      
      Tested with tcp_probe.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      3b7d14e9
  6. 20 Jul, 2016 1 commit
  7. 19 Jul, 2016 16 commits
  8. 12 Jul, 2016 3 commits
    • Steve Capper's avatar
      arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs · f8d9f924
      Steve Capper authored
      It can be useful for JIT software to be aware of MIDR_EL1 and
      REVIDR_EL1 to ascertain the presence of any core errata that could
      affect code generation.
      
      This patch exposes these registers through sysfs:
      
      /sys/devices/system/cpu/cpu$ID/regs/identification/midr_el1
      /sys/devices/system/cpu/cpu$ID/regs/identification/revidr_el1
      
      where $ID is the cpu number. For big.LITTLE systems, one can have a
      mixture of cores (e.g. Cortex A53 and Cortex A57), thus all CPUs need
      to be enumerated.
      
      If the kernel does not have valid information to populate these entries
      with, an empty string is returned to userspace.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSteve Capper <steve.capper@linaro.org>
      [suzuki.poulose@arm.com: ABI documentation updates, hotplug notifiers, kobject changes]
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      f8d9f924
    • Kevin Brodsky's avatar
      arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO · 49eea433
      Kevin Brodsky authored
      So far the arm64 clock_gettime() vDSO implementation only supported
      the following clocks, falling back to the syscall for the others:
      - CLOCK_REALTIME{,_COARSE}
      - CLOCK_MONOTONIC{,_COARSE}
      
      This patch adds support for the CLOCK_MONOTONIC_RAW clock, taking
      advantage of the recent refactoring of the vDSO time functions. Like
      the non-_COARSE clocks, this only works when the "arch_sys_counter"
      clocksource is in use (allowing us to read the current time from the
      virtual counter register), otherwise we also have to fall back to the
      syscall.
      
      Most of the data is shared with CLOCK_MONOTONIC, and the algorithm is
      similar. The reference implementation in kernel/time/timekeeping.c
      shows that:
      - CLOCK_MONOTONIC = tk->wall_to_monotonic + tk->xtime_sec +
        timekeeping_get_ns(&tk->tkr_mono)
      - CLOCK_MONOTONIC_RAW = tk->raw_time + timekeeping_get_ns(&tk->tkr_raw)
      - tkr_mono and tkr_raw are identical (in particular, same
        clocksource), except these members:
        * mult (only mono's multiplier is NTP-adjusted)
        * xtime_nsec (always 0 for raw)
      
      Therefore, tk->raw_time and tkr_raw->mult are now also stored in the
      vDSO data page.
      
      Cc: Ali Saidi <ali.saidi@arm.com>
      Signed-off-by: default avatarKevin Brodsky <kevin.brodsky@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      49eea433
    • Kevin Brodsky's avatar
      arm64: Refactor vDSO time functions · b33f491f
      Kevin Brodsky authored
      Time functions are directly implemented in assembly in arm64, and it
      is desirable to keep it this way for performance reasons (everything
      fits in registers, so that the stack is not used at all). However, the
      current implementation is quite difficult to read and understand (even
      considering it's assembly).  Additionally, due to the structure of
      __kernel_clock_gettime, which heavily uses conditional branches to
      share code between the different clocks, it is difficult to support a
      new clock without making the branches even harder to follow.
      
      This commit completely refactors the structure of clock_gettime (and
      gettimeofday along the way) while keeping exactly the same algorithms.
      We no longer try to share code; instead, macros provide common
      operations. This new approach comes with a number of advantages:
      - In clock_gettime, clock implementations are no longer interspersed,
        making them much more readable. Additionally, macros only use
        registers passed as arguments or reserved with .req, this way it is
        easy to make sure that registers are properly allocated. To avoid a
        large number of branches in a given execution path, a jump table is
        used; a normal execution uses 3 unconditional branches.
      - __do_get_tspec has been replaced with 2 macros (get_ts_clock_mono,
        get_clock_shifted_nsec) and explicit loading of data from the vDSO
        page. Consequently, clock_gettime and gettimeofday are now leaf
        functions, and saving x30 (lr) is no longer necessary.
      - Variables protected by tb_seq_count are now loaded all at once,
        allowing to merge the seqcnt_read macro into seqcnt_check.
      - For CLOCK_REALTIME_COARSE, removed an unused load of the wall to
        monotonic timespec.
      - For CLOCK_MONOTONIC_COARSE, removed a few shift instructions.
      
      Obviously, the downside of sharing less code is an increase in code
      size. However since the vDSO has its own code page, this does not
      really matter, as long as the size of the DSO remains below 4 kB. For
      now this should be all right:
                          Before  After
        vdso.so size (B)  2776    3000
      Signed-off-by: default avatarKevin Brodsky <kevin.brodsky@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      b33f491f
  9. 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
  10. 08 Jul, 2016 3 commits
    • Lorenzo Pieralisi's avatar
      arm64: mm: change IOMMU notifier action to attach DMA ops · 16c11325
      Lorenzo Pieralisi authored
      Current bus notifier in ARM64 (__iommu_attach_notifier)
      attempts to attach dma_ops to a device on BUS_NOTIFY_ADD_DEVICE
      action notification.
      
      This will cause issues on ACPI based systems, where PCI devices
      can be added before the IOMMUs the devices are attached to
      had a chance to be probed, causing failures on attempts to
      attach dma_ops in that the domain for the respective IOMMU
      may not be set-up yet by the time the bus notifier is run.
      
      Devices dma_ops do not require to be set-up till the matching
      device drivers are probed. This means that instead of running
      the notifier attaching dma_ops to devices (__iommu_attach_notifier)
      on BUS_NOTIFY_ADD_DEVICE action, it can be run just before the
      device driver is bound to the device in question (on action
      BUS_NOTIFY_BIND_DRIVER) so that it is certain that its IOMMU
      group and domain are set-up accordingly at the time the
      notifier is triggered.
      
      This patch changes the notifier action upon which dma_ops
      are attached to devices and defer it to driver binding time,
      so that IOMMU devices have a chance to be probed and to register
      their bus notifiers before the dma_ops attach sequence for a
      device is actually carried out.
      
      As a result we also no longer need worry about racing with
      iommu_bus_notifier(), or about retrying the queue in case devices
      were added too early on DT-based systems, so clean up the notifier
      itself plus the additional workaround from 722ec35f ("arm64:
      dma-mapping: fix handling of devices registered before arch_initcall")
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      [rm: get rid of other now-redundant bits]
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      16c11325
    • Marc Zyngier's avatar
      drivers/perf: arm-pmu: Handle per-interrupt affinity mask · 19a469a5
      Marc Zyngier authored
      On a big-little system, PMUs can be wired to CPUs using per CPU
      interrups (PPI). In this case, it is important to make sure that
      the enable/disable do happen on the right set of CPUs.
      
      So instead of relying on the interrupt-affinity property, we can
      use the actual percpu affinity that DT exposes as part of the
      interrupt specifier. The DT binding is also updated to reflect
      the fact that the interrupt-affinity property shouldn't be used
      in that case.
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Tested-by: default avatarCaesar Wang <wxt@rock-chips.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      19a469a5
    • 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
  11. 01 Jul, 2016 5 commits