1. 02 Mar, 2017 1 commit
  2. 15 Feb, 2017 1 commit
    • Mark Rutland's avatar
      arm64: traps: correctly handle MRS/MSR with XZR · 8b6e70fc
      Mark Rutland authored
      
      
      Currently we hand-roll XZR-safe register handling in
      user_cache_maint_handler(), though we forget to do the same in
      ctr_read_handler(), and may erroneously write back to the user SP rather
      than XZR.
      
      Use the new helpers to handle these cases correctly and consistently.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 116c81f4
      
       ("arm64: Work around systems with mismatched cache line sizes")
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8b6e70fc
  3. 27 Jan, 2017 1 commit
    • Mark Rutland's avatar
      arm64: handle sys and undef traps consistently · 49f6cba6
      Mark Rutland authored
      
      
      If an EL0 instruction in the SYS class triggers an exception, do_sysintr
      looks for a sys64_hook matching the instruction, and if none is found,
      injects a SIGILL. This mirrors what we do for undefined instruction
      encodings in do_undefinstr, where we look for an undef_hook matching the
      instruction, and if none is found, inject a SIGILL.
      
      Over time, new SYS instruction encodings may be allocated. Prior to
      allocation, exceptions resulting from these would be handled by
      do_undefinstr, whereas after allocation these may be handled by
      do_sysintr.
      
      To ensure that we have consistent behaviour if and when this happens, it
      would be beneficial to have do_sysinstr fall back to do_undefinstr.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarSuzuki Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      49f6cba6
  4. 19 Jan, 2017 1 commit
    • Mark Rutland's avatar
      arm64: avoid returning from bad_mode · 7d9e8f71
      Mark Rutland authored
      Generally, taking an unexpected exception should be a fatal event, and
      bad_mode is intended to cater for this. However, it should be possible
      to contain unexpected synchronous exceptions from EL0 without bringing
      the kernel down, by sending a SIGILL to the task.
      
      We tried to apply this approach in commit 9955ac47
      
       ("arm64:
      don't kill the kernel on a bad esr from el0"), by sending a signal for
      any bad_mode call resulting from an EL0 exception.
      
      However, this also applies to other unexpected exceptions, such as
      SError and FIQ. The entry paths for these exceptions branch to bad_mode
      without configuring the link register, and have no kernel_exit. Thus, if
      we take one of these exceptions from EL0, bad_mode will eventually
      return to the original user link register value.
      
      This patch fixes this by introducing a new bad_el0_sync handler to cater
      for the recoverable case, and restoring bad_mode to its original state,
      whereby it calls panic() and never returns. The recoverable case
      branches to bad_el0_sync with a bl, and returns to userspace via the
      usual ret_to_user mechanism.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: 9955ac47
      
       ("arm64: don't kill the kernel on a bad esr from el0")
      Reported-by: default avatarMark Salter <msalter@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      7d9e8f71
  5. 10 Jan, 2017 1 commit
  6. 21 Nov, 2016 1 commit
    • Catalin Marinas's avatar
      arm64: Disable TTBR0_EL1 during normal kernel execution · 39bc88e5
      Catalin Marinas authored
      
      
      When the TTBR0 PAN feature is enabled, the kernel entry points need to
      disable access to TTBR0_EL1. The PAN status of the interrupted context
      is stored as part of the saved pstate, reusing the PSR_PAN_BIT (22).
      Restoring access to TTBR0_EL1 is done on exception return if returning
      to user or returning to a context where PAN was disabled.
      
      Context switching via switch_mm() must defer the update of TTBR0_EL1
      until a return to user or an explicit uaccess_enable() call.
      
      Special care needs to be taken for two cases where TTBR0_EL1 is set
      outside the normal kernel context switch operation: EFI run-time
      services (via efi_set_pgd) and CPU suspend (via cpu_(un)install_idmap).
      Code has been added to avoid deferred TTBR0_EL1 switching as in
      switch_mm() and restore the reserved TTBR0_EL1 when uninstalling the
      special TTBR0_EL1.
      
      User cache maintenance (user_cache_maint_handler and
      __flush_cache_user_range) needs the TTBR0_EL1 re-instated since the
      operations are performed by user virtual address.
      
      This patch also removes a stale comment on the switch_mm() function.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      39bc88e5
  7. 11 Nov, 2016 3 commits
    • Mark Rutland's avatar
      arm64: prep stack walkers for THREAD_INFO_IN_TASK · 9bbd4c56
      Mark Rutland authored
      
      
      When CONFIG_THREAD_INFO_IN_TASK is selected, task stacks may be freed
      before a task is destroyed. To account for this, the stacks are
      refcounted, and when manipulating the stack of another task, it is
      necessary to get/put the stack to ensure it isn't freed and/or re-used
      while we do so.
      
      This patch reworks the arm64 stack walking code to account for this.
      When CONFIG_THREAD_INFO_IN_TASK is not selected these perform no
      refcounting, and this should only be a structural change that does not
      affect behaviour.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      9bbd4c56
    • Mark Rutland's avatar
      arm64: traps: simplify die() and __die() · 876e7a38
      Mark Rutland authored
      
      
      In arm64's die and __die routines we pass around a thread_info, and
      subsequently use this to determine the relevant task_struct, and the end
      of the thread's stack. Subsequent patches will decouple thread_info from
      the stack, and this approach will no longer work.
      
      To figure out the end of the stack, we can use the new generic
      end_of_stack() helper. As we only call __die() from die(), and die()
      always deals with the current task, we can remove the parameter and have
      both acquire current directly, which also makes it clear that __die
      can't be called for arbitrary tasks.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      876e7a38
    • Mark Rutland's avatar
      arm64: factor out current_stack_pointer · a9ea0017
      Mark Rutland authored
      
      
      We define current_stack_pointer in <asm/thread_info.h>, though other
      files and header relying upon it do not have this necessary include, and
      are thus fragile to changes in the header soup.
      
      Subsequent patches will affect the header soup such that directly
      including <asm/thread_info.h> may result in a circular header include in
      some of these cases, so we can't simply include <asm/thread_info.h>.
      
      Instead, factor current_thread_info into its own header, and have all
      existing users include this explicitly.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      a9ea0017
  8. 20 Oct, 2016 2 commits
    • James Morse's avatar
      arm64: cpufeature: Schedule enable() calls instead of calling them via IPI · 2a6dcb2b
      James Morse authored
      
      
      The enable() call for a cpufeature/errata is called using on_each_cpu().
      This issues a cross-call IPI to get the work done. Implicitly, this
      stashes the running PSTATE in SPSR when the CPU receives the IPI, and
      restores it when we return. This means an enable() call can never modify
      PSTATE.
      
      To allow PAN to do this, change the on_each_cpu() call to use
      stop_machine(). This schedules the work on each CPU which allows
      us to modify PSTATE.
      
      This involves changing the protype of all the enable() functions.
      
      enable_cpu_capabilities() is called during boot and enables the feature
      on all online CPUs. This path now uses stop_machine(). CPU features for
      hotplug'd CPUs are enabled by verify_local_cpu_features() which only
      acts on the local CPU, and can already modify the running PSTATE as it
      is called from secondary_start_kernel().
      Reported-by: default avatarTony Thompson <anthony.thompson@arm.com>
      Reported-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      2a6dcb2b
    • Andre Przywara's avatar
      arm64: Cortex-A53 errata workaround: check for kernel addresses · 87261d19
      Andre Przywara authored
      Commit 7dd01aef ("arm64: trap userspace "dc cvau" cache operation on
      errata-affected core") adds code to execute cache maintenance instructions
      in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
      It turns out that the address hasn't been checked to be a valid user
      space address, allowing userland to clean cache lines in kernel space.
      Fix this by introducing an address check before executing the
      instructions on behalf of userland.
      
      Since the address doesn't come via a syscall parameter, we can't just
      reject tagged pointers and instead have to remove the tag when checking
      against the user address limit.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 7dd01aef
      
       ("arm64: trap userspace "dc cvau" cache operation on errata-affected core")
      Reported-by: default avatarKristina Martsenko <kristina.martsenko@arm.com>
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      [will: rework commit message + replace access_ok with max_user_addr()]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      87261d19
  9. 26 Sep, 2016 1 commit
    • Mark Rutland's avatar
      arm64: fix dump_backtrace/unwind_frame with NULL tsk · b5e7307d
      Mark Rutland authored
      In some places, dump_backtrace() is called with a NULL tsk parameter,
      e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in
      core code. The expectation is that this is treated as if current were
      passed instead of NULL. Similar is true of unwind_frame().
      
      Commit a80a0eb7
      
       ("arm64: make irq_stack_ptr more robust") didn't
      take this into account. In dump_backtrace() it compares tsk against
      current *before* we check if tsk is NULL, and in unwind_frame() we never
      set tsk if it is NULL.
      
      Due to this, we won't initialise irq_stack_ptr in either function. In
      dump_backtrace() this results in calling dump_mem() for memory
      immediately above the IRQ stack range, rather than for the relevant
      range on the task stack. In unwind_frame we'll reject unwinding frames
      on the IRQ stack.
      
      In either case this results in incomplete or misleading backtrace
      information, but is not otherwise problematic. The initial percpu areas
      (including the IRQ stacks) are allocated in the linear map, and dump_mem
      uses __get_user(), so we shouldn't access anything with side-effects,
      and will handle holes safely.
      
      This patch fixes the issue by having both functions handle the NULL tsk
      case before doing anything else with tsk.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Fixes: a80a0eb7
      
       ("arm64: make irq_stack_ptr more robust")
      Acked-by: default avatarJames Morse <james.morse@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yang Shi <yang.shi@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      b5e7307d
  10. 09 Sep, 2016 2 commits
    • Suzuki K Poulose's avatar
      arm64: Work around systems with mismatched cache line sizes · 116c81f4
      Suzuki K Poulose authored
      
      
      Systems with differing CPU i-cache/d-cache line sizes can cause
      problems with the cache management by software when the execution
      is migrated from one to another. Usually, the application reads
      the cache size on a CPU and then uses that length to perform cache
      operations. However, if it gets migrated to another CPU with a smaller
      cache line size, things could go completely wrong. To prevent such
      cases, always use the smallest cache line size among the CPUs. The
      kernel CPU feature infrastructure already keeps track of the safe
      value for all CPUID registers including CTR. This patch works around
      the problem by :
      
      For kernel, dynamically patch the kernel to read the cache size
      from the system wide copy of CTR_EL0.
      
      For applications, trap read accesses to CTR_EL0 (by clearing the SCTLR.UCT)
      and emulate the mrs instruction to return the system wide safe value
      of CTR_EL0.
      
      For faster access (i.e, avoiding to lookup the system wide value of CTR_EL0
      via read_system_reg), we keep track of the pointer to table entry for
      CTR_EL0 in the CPU feature infrastructure.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      116c81f4
    • Suzuki K Poulose's avatar
      arm64: Refactor sysinstr exception handling · 9dbd5bb2
      Suzuki K Poulose authored
      
      
      Right now we trap some of the user space data cache operations
      based on a few Errata (ARM 819472, 826319, 827319 and 824069).
      We need to trap userspace access to CTR_EL0, if we detect mismatched
      cache line size. Since both these traps share the EC, refactor
      the handler a little bit to make it a bit more reader friendly.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      9dbd5bb2
  11. 01 Jul, 2016 2 commits
  12. 21 Jun, 2016 2 commits
    • Mark Rutland's avatar
      arm64: add macro to extract ESR_ELx.EC · 275f344b
      Mark Rutland authored
      
      
      Several places open-code extraction of the EC field from an ESR_ELx
      value, in subtly different ways. This is unfortunate duplication and
      variation, and the precise logic used to extract the field is a
      distraction.
      
      This patch adds a new macro, ESR_ELx_EC(), to extract the EC field from
      an ESR_ELx value in a consistent fashion.
      
      Existing open-coded extractions in core arm64 code are moved over to the
      new helper. KVM code is left as-is for the moment.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarHuang Shijie <shijie.huang@arm.com>
      Cc: Dave P Martin <dave.martin@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      275f344b
    • Mark Rutland's avatar
      arm64: simplify dump_mem · 7ceb3a10
      Mark Rutland authored
      Currently dump_mem attempts to dump memory in 64-bit chunks when
      reporting a failure in 64-bit code, or 32-bit chunks when reporting a
      failure in 32-bit code. We added code to handle these two cases
      separately in commit e147ae6d
      
       ("arm64: modify the dump mem for
      64 bit addresses").
      
      However, in all cases dump_mem is called, the failing context is a
      kernel rather than user context. Additionally dump_mem is assumed to
      only be used for kernel contexts, as internally it switches to
      KERNEL_DS, and its callers pass kernel stack bounds.
      
      This patch removes the redundant 32-bit chunk logic and associated
      compat parameter, largely reverting the aforementioned commit. For the
      call in __die(), the check of in_interrupt() is removed also, as __die()
      is only called in response to faults from the kernel's exception level,
      and thus the !user_mode(regs) check is sufficient. Were this not the
      case, the used of task_stack_page(tsk) to generate the stack bounds
      would be erroneous.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      7ceb3a10
  13. 14 Jun, 2016 1 commit
    • Mark Rutland's avatar
      arm64: fix dump_instr when PAN and UAO are in use · c5cea06b
      Mark Rutland authored
      
      
      If the kernel is set to show unhandled signals, and a user task does not
      handle a SIGILL as a result of an instruction abort, we will attempt to
      log the offending instruction with dump_instr before killing the task.
      
      We use dump_instr to log the encoding of the offending userspace
      instruction. However, dump_instr is also used to dump instructions from
      kernel space, and internally always switches to KERNEL_DS before dumping
      the instruction with get_user. When both PAN and UAO are in use, reading
      a user instruction via get_user while in KERNEL_DS will result in a
      permission fault, which leads to an Oops.
      
      As we have regs corresponding to the context of the original instruction
      abort, we can inspect this and only flip to KERNEL_DS if the original
      abort was taken from the kernel, avoiding this issue. At the same time,
      remove the redundant (and incorrect) comments regarding the order
      dump_mem and dump_instr are called in.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: <stable@vger.kernel.org> #4.6+
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Tested-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Fixes: 57f4959b
      
       ("arm64: kernel: Add support for User Access Override")
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c5cea06b
  14. 03 Jun, 2016 1 commit
    • Mark Rutland's avatar
      arm64: report CPU number in bad_mode · 8051f4d1
      Mark Rutland authored
      
      
      If we take an exception we don't expect (e.g. SError), we report this in
      the bad_mode handler with pr_crit. Depending on the configured log
      level, we may or may not log additional information in functions called
      subsequently. Notably, the messages in dump_stack (including the CPU
      number) are printed with KERN_DEFAULT and may not appear.
      
      Some exceptions have an IMPLEMENTATION DEFINED ESR_ELx.ISS encoding, and
      knowing the CPU number is crucial to correctly decode them. To ensure
      that this is always possible, we should log the CPU number along with
      the ESR_ELx value, so we are not reliant on subsequent logs or
      additional printk configuration options.
      
      This patch logs the CPU number in bad_mode such that it is possible for
      a developer to decode these exceptions, provided access to sufficient
      documentation.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarAl Grant <Al.Grant@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dave Martin <dave.martin@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8051f4d1
  15. 12 Feb, 2016 1 commit
  16. 21 Dec, 2015 3 commits
    • Will Deacon's avatar
      arm64: traps: address fallout from printk -> pr_* conversion · c9cd0ed9
      Will Deacon authored
      Commit ac7b406c
      
       ("arm64: Use pr_* instead of printk") was a fairly
      mindless s/printk/pr_*/ change driven by a complaint from checkpatch.
      
      As is usual with such changes, this has led to some odd behaviour on
      arm64:
      
        * syslog now picks up the "pr_emerg" line from dump_backtrace, but not
          the actual trace, which leads to a bunch of "kernel:Call trace:"
          lines in the log
      
        * __{pte,pmd,pgd}_error print at KERN_CRIT, as opposed to KERN_ERR
          which is used by other architectures.
      
      This patch restores the original printk behaviour for dump_backtrace
      and downgrade the pgtable error macros to KERN_ERR.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c9cd0ed9
    • AKASHI Takahiro's avatar
      arm64: ftrace: fix a stack tracer's output under function graph tracer · 20380bb3
      AKASHI Takahiro authored
      
      
      Function graph tracer modifies a return address (LR) in a stack frame
      to hook a function return. This will result in many useless entries
      (return_to_handler) showing up in
       a) a stack tracer's output
       b) perf call graph (with perf record -g)
       c) dump_backtrace (at panic et al.)
      
      For example, in case of a),
        $ echo function_graph > /sys/kernel/debug/tracing/current_tracer
        $ echo 1 > /proc/sys/kernel/stack_trace_enabled
        $ cat /sys/kernel/debug/tracing/stack_trace
              Depth    Size   Location    (54 entries)
              -----    ----   --------
        0)     4504      16   gic_raise_softirq+0x28/0x150
        1)     4488      80   smp_cross_call+0x38/0xb8
        2)     4408      48   return_to_handler+0x0/0x40
        3)     4360      32   return_to_handler+0x0/0x40
        ...
      
      In case of b),
        $ echo function_graph > /sys/kernel/debug/tracing/current_tracer
        $ perf record -e mem:XXX:x -ag -- sleep 10
        $ perf report
                        ...
                        |          |          |--0.22%-- 0x550f8
                        |          |          |          0x10888
                        |          |          |          el0_svc_naked
                        |          |          |          sys_openat
                        |          |          |          return_to_handler
                        |          |          |          return_to_handler
                        ...
      
      In case of c),
        $ echo function_graph > /sys/kernel/debug/tracing/current_tracer
        $ echo c > /proc/sysrq-trigger
        ...
        Call trace:
        [<ffffffc00044d3ac>] sysrq_handle_crash+0x24/0x30
        [<ffffffc000092250>] return_to_handler+0x0/0x40
        [<ffffffc000092250>] return_to_handler+0x0/0x40
        ...
      
      This patch replaces such entries with real addresses preserved in
      current->ret_stack[] at unwind_frame(). This way, we can cover all
      the cases.
      Reviewed-by: default avatarJungseok Lee <jungseoklee85@gmail.com>
      Signed-off-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      [will: fixed minor context changes conflicting with irq stack bits]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      20380bb3
    • AKASHI Takahiro's avatar
      arm64: pass a task parameter to unwind_frame() · fe13f95b
      AKASHI Takahiro authored
      
      
      Function graph tracer modifies a return address (LR) in a stack frame
      to hook a function's return. This will result in many useless entries
      (return_to_handler) showing up in a call stack list.
      We will fix this problem in a later patch ("arm64: ftrace: fix a stack
      tracer's output under function graph tracer"). But since real return
      addresses are saved in ret_stack[] array in struct task_struct,
      unwind functions need to be notified of, in addition to a stack pointer
      address, which task is being traced in order to find out real return
      addresses.
      
      This patch extends unwind functions' interfaces by adding an extra
      argument of a pointer to task_struct.
      Signed-off-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      fe13f95b
  17. 08 Dec, 2015 1 commit
  18. 19 Oct, 2015 1 commit
    • Jungseok Lee's avatar
      arm64: Synchronise dump_backtrace() with perf callchain · 9f93f3e9
      Jungseok Lee authored
      
      
      Unlike perf callchain relying on walk_stackframe(), dump_backtrace()
      has its own backtrace logic. A major difference between them is the
      moment a symbol is recorded. Perf writes down a symbol *before*
      calling unwind_frame(), but dump_backtrace() prints it out *after*
      unwind_frame(). As a result, the last valid symbol cannot be hooked
      in case of dump_backtrace(). This patch addresses the issue as
      synchronising dump_backtrace() with perf callchain.
      
      A simple test and its results are as follows:
      
      - crash trigger
      
       $ sudo echo c > /proc/sysrq-trigger
      
      - current status
      
       Call trace:
       [<fffffe00003dc738>] sysrq_handle_crash+0x24/0x30
       [<fffffe00003dd2ac>] __handle_sysrq+0x128/0x19c
       [<fffffe00003dd730>] write_sysrq_trigger+0x60/0x74
       [<fffffe0000249fc4>] proc_reg_write+0x84/0xc0
       [<fffffe00001f2638>] __vfs_write+0x44/0x104
       [<fffffe00001f2e60>] vfs_write+0x98/0x1a8
       [<fffffe00001f3730>] SyS_write+0x50/0xb0
      
      - with this change
      
       Call trace:
       [<fffffe00003dc738>] sysrq_handle_crash+0x24/0x30
       [<fffffe00003dd2ac>] __handle_sysrq+0x128/0x19c
       [<fffffe00003dd730>] write_sysrq_trigger+0x60/0x74
       [<fffffe0000249fc4>] proc_reg_write+0x84/0xc0
       [<fffffe00001f2638>] __vfs_write+0x44/0x104
       [<fffffe00001f2e60>] vfs_write+0x98/0x1a8
       [<fffffe00001f3730>] SyS_write+0x50/0xb0
       [<fffffe00000939ec>] el0_svc_naked+0x20/0x28
      
      Note that this patch does not cover a case where MMU is disabled. The
      last stack frame of swapper, for example, has PC in a form of physical
      address. Unfortunately, a simple conversion using phys_to_virt() cannot
      cover all scenarios since PC is retrieved from LR - 4, not LR. It is
      a big tradeoff to change both head.S and unwind_frame() for only a few
      of symbols in *.S. Thus, this hunk does not take care of the case.
      
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarJungseok Lee <jungseoklee85@gmail.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      9f93f3e9
  19. 27 Jul, 2015 4 commits
    • Dave P Martin's avatar
      arm64/BUG: Show explicit backtrace for WARNs · a4653228
      Dave P Martin authored
      
      
      The generic slowpath WARN implementation prints a backtrace, but
      the report_bug() based implementation does not, opting to print the
      registers instead which is generally not as useful.
      
      Ideally, report_bug() should be fixed to make the behaviour more
      consistent, but in the meantime this patch generates a backtrace
      directly from the arm64 backend instead so that this functionality
      is not lost with the migration to report_bug().
      
      As a side-effect, the backtrace will be outside the oops end
      marker, but that's hard to avoid without modifying generic code.
      
      This patch can go away if report_bug() grows the ability in the
      future to generate a backtrace directly or call an arch hook at the
      appropriate time.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      a4653228
    • Dave P Martin's avatar
      arm64/BUG: Use BRK instruction for generic BUG traps · 9fb7410f
      Dave P Martin authored
      
      
      Currently, the minimal default BUG() implementation from asm-
      generic is used for arm64.
      
      This patch uses the BRK software breakpoint instruction to generate
      a trap instead, similarly to most other arches, with the generic
      BUG code generating the dmesg boilerplate.
      
      This allows bug metadata to be moved to a separate table and
      reduces the amount of inline code at BUG and WARN sites.  This also
      avoids clobbering any registers before they can be dumped.
      
      To mitigate the size of the bug table further, this patch makes
      use of the existing infrastructure for encoding addresses within
      the bug table as 32-bit offsets instead of absolute pointers.
      (Note that this limits the kernel size to 2GB.)
      
      Traps are registered at arch_initcall time for aarch64, but BUG
      has minimal real dependencies and it is desirable to be able to
      generate bug splats as early as possible.  This patch redirects
      all debug exceptions caused by BRK directly to bug_handler() until
      the full debug exception support has been initialised.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      9fb7410f
    • Will Deacon's avatar
      arm64: force CONFIG_SMP=y and remove redundant #ifdefs · 4b3dc967
      Will Deacon authored
      
      
      Nobody seems to be producing !SMP systems anymore, so this is just
      becoming a source of kernel bugs, particularly if people want to use
      coherent DMA with non-shared pages.
      
      This patch forces CONFIG_SMP=y for arm64, removing a modest amount of
      code in the process.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      4b3dc967
    • Rohit Thapliyal's avatar
      arm64: modify the dump mem for 64 bit addresses · e147ae6d
      Rohit Thapliyal authored
      
      
      On 64bit kernel, the dump_mem gives 32 bit addresses
      on the stack dump. This gives unorganized information regarding
      the 64bit values on the stack. Hence, modified to get a complete 64bit memory
      dump.
      
      With patch:
      [   93.534801] Process insmod (pid: 1587, stack limit = 0xffffffc976be4058)
      [   93.541441] Stack: (0xffffffc976be7cf0 to 0xffffffc976be8000)
      [   93.547136] 7ce0:                                   ffffffc976be7d00 ffffffc00008163c
      [   93.554898] 7d00: ffffffc976be7d40 ffffffc0000f8a44 ffffffc00098ef38 ffffffbffc000088
      [   93.562659] 7d20: ffffffc00098ef50 ffffffbffc0000c0 0000000000000001 ffffffbffc000070
      [   93.570419] 7d40: ffffffc976be7e40 ffffffc0000f935c 0000000000000000 000000002b424090
      [   93.578179] 7d60: 000000002b424010 0000007facc555f4 0000000080000000 0000000000000015
      [   93.585937] 7d80: 0000000000000116 0000000000000069 ffffffc00097b000 ffffffc976be4000
      [   93.593694] 7da0: 0000000000000064 0000000000000072 000000000000006e 000000000000003f
      [   93.601453] 7dc0: 000000000000feff 000000000000fff1 ffffffbffc002028 0000000000000124
      [   93.609211] 7de0: ffffffc976be7e10 0000000000000001 ffffff8000000000 ffffffbbffff0000
      [   93.616969] 7e00: ffffffc976be7e60 0000000000000000 0000000000000000 0000000000000000
      [   93.624726] 7e20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [   93.632484] 7e40: 0000007fcc474550 ffffffc0000841ec 000000002b424010 0000007facda0710
      [   93.640241] 7e60: ffffffffffffffff ffffffc0000be6dc ffffff80007d2000 000000000001c010
      [   93.647999] 7e80: ffffff80007e0ae0 ffffff80007e09d0 ffffff80007edf70 0000000000000288
      [   93.655757] 7ea0: 00000000000002e8 0000000000000000 0000000000000000 0000001c0000001b
      [   93.663514] 7ec0: 0000000000000009 0000000000000007 000000002b424090 000000000001c010
      [   93.671272] 7ee0: 000000002b424010 0000007faccd3a48 0000000000000000 0000000000000000
      [   93.679030] 7f00: 0000007fcc4743f8 0000007fcc4743f8 0000000000000069 0000000000000003
      [   93.686787] 7f20: 0101010101010101 0000000000000004 0000000000000020 00000000000003f3
      [   93.694544] 7f40: 0000007facb95664 0000007facda7030 0000007facc555d0 0000000000498378
      [   93.702301] 7f60: 0000000000000000 000000002b424010 0000007facda0710 000000002b424090
      [   93.710058] 7f80: 0000007fcc474698 0000000000498000 0000007fcc474ebb 0000000000474f58
      [   93.717815] 7fa0: 0000000000498000 0000000000000000 0000000000000000 0000007fcc474550
      [   93.725573] 7fc0: 00000000004104bc 0000007fcc474430 0000007facc555f4 0000000080000000
      [   93.733330] 7fe0: 000000002b424090 0000000000000069 0950020128000244 4104000008000004
      [   93.741084] Call trace:
      
      The above output makes a debugger life a lot more easier.
      Signed-off-by: default avatarRohit Thapliyal <r.thapliyal@samsung.com>
      Signed-off-by: default avatarManinder Singh <maninder1.s@samsung.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e147ae6d
  20. 03 Jul, 2015 1 commit
  21. 19 Jun, 2015 1 commit
    • Vladimir Murzin's avatar
      arm64: use private ratelimit state along with show_unhandled_signals · 86dca36e
      Vladimir Murzin authored
      
      
      printk_ratelimit() shares the ratelimiting state with other callers what
      may lead to scenarios where at the time we want to print out debug
      information we already limited, so nothing appears in the dmesg - this
      makes exception-trace quite poor helper in debugging.
      
      Additionally, we have imbalance with some messages limited with global
      ratelimit state and other messages limited with their private state
      defined via pr_*_ratelimited().
      
      To address this inconsistency show_unhandled_signals_ratelimited()
      macro is introduced and caller sites are converted to use it.
      Signed-off-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      86dca36e
  22. 15 Jan, 2015 1 commit
  23. 20 Nov, 2014 1 commit
  24. 08 Sep, 2014 1 commit
  25. 23 Jul, 2014 1 commit
    • Jungseok Lee's avatar
      arm64: mm: Implement 4 levels of translation tables · c79b954b
      Jungseok Lee authored
      
      
      This patch implements 4 levels of translation tables since 3 levels
      of page tables with 4KB pages cannot support 40-bit physical address
      space described in [1] due to the following issue.
      
      It is a restriction that kernel logical memory map with 4KB + 3 levels
      (0xffffffc000000000-0xffffffffffffffff) cannot cover RAM region from
      544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
      mapping for this region in map_mem function since __phys_to_virt for
      this region reaches to address overflow.
      
      If SoC design follows the document, [1], over 32GB RAM would be placed
      from 544GB. Even 64GB system is supposed to use the region from 544GB
      to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
      of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
      
      However, it is recommended 4 levels of page table should be only enabled
      if memory map is too sparse or there is about 512GB RAM.
      
      References
      ----------
      [1]: Principles of ARM Memory Maps, White Paper, Issue C
      Signed-off-by: default avatarJungseok Lee <jays.lee@samsung.com>
      Reviewed-by: default avatarSungjinn Chung <sungjinn.chung@samsung.com>
      Acked-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Reviewed-by: default avatarSteve Capper <steve.capper@linaro.org>
      [catalin.marinas@arm.com: MEMBLOCK_INITIAL_LIMIT removed, same as PUD_SIZE]
      [catalin.marinas@arm.com: early_ioremap_init() updated for 4 levels]
      [catalin.marinas@arm.com: 48-bit VA depends on BROKEN until KVM is fixed]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarJungseok Lee <jungseoklee85@gmail.com>
      c79b954b
  26. 17 Jul, 2014 1 commit
  27. 09 May, 2014 1 commit
  28. 12 Jun, 2013 1 commit
  29. 31 May, 2013 1 commit