1. 27 7月, 2015 1 次提交
  2. 22 7月, 2015 1 次提交
  3. 09 7月, 2015 1 次提交
  4. 17 6月, 2015 1 次提交
    • M
      arm64: entry: fix context tracking for el0_sp_pc · 46b0567c
      Mark Rutland 提交于
      Commit 6c81fe79 ("arm64: enable context tracking") did not
      update el0_sp_pc to use ct_user_exit, but this appears to have been
      unintentional. In commit 6ab6463a ("arm64: adjust el0_sync so
      that a function can be called") we made x0 available, and in the return
      to userspace we call ct_user_enter in the kernel_exit macro.
      
      Due to this, we currently don't correctly inform RCU of the user->kernel
      transition, and may erroneously account for time spent in the kernel as
      if we were in an extended quiescent state when CONFIG_CONTEXT_TRACKING
      is enabled.
      
      As we do record the kernel->user transition, a userspace application
      making accesses from an unaligned stack pointer can demonstrate the
      imbalance, provoking the following warning:
      
      ------------[ cut here ]------------
      WARNING: CPU: 2 PID: 3660 at kernel/context_tracking.c:75 context_tracking_enter+0xd8/0xe4()
      Modules linked in:
      CPU: 2 PID: 3660 Comm: a.out Not tainted 4.1.0-rc7+ #8
      Hardware name: ARM Juno development board (r0) (DT)
      Call trace:
      [<ffffffc000089914>] dump_backtrace+0x0/0x124
      [<ffffffc000089a48>] show_stack+0x10/0x1c
      [<ffffffc0005b3cbc>] dump_stack+0x84/0xc8
      [<ffffffc0000b3214>] warn_slowpath_common+0x98/0xd0
      [<ffffffc0000b330c>] warn_slowpath_null+0x14/0x20
      [<ffffffc00013ada4>] context_tracking_enter+0xd4/0xe4
      [<ffffffc0005b534c>] preempt_schedule_irq+0xd4/0x114
      [<ffffffc00008561c>] el1_preempt+0x4/0x28
      [<ffffffc0001b8040>] exit_files+0x38/0x4c
      [<ffffffc0000b5b94>] do_exit+0x430/0x978
      [<ffffffc0000b614c>] do_group_exit+0x40/0xd4
      [<ffffffc0000c0208>] get_signal+0x23c/0x4f4
      [<ffffffc0000890b4>] do_signal+0x1ac/0x518
      [<ffffffc000089650>] do_notify_resume+0x5c/0x68
      ---[ end trace 963c192600337066 ]---
      
      This patch adds the missing ct_user_exit to the el0_sp_pc entry path,
      correcting the context tracking for this case.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Fixes: 6c81fe79 ("arm64: enable context tracking")
      Cc: <stable@vger.kernel.org> # v3.17+
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      46b0567c
  5. 09 6月, 2015 1 次提交
    • J
      arm64: fix missing syscall trace exit · 04d7e098
      Josh Stone 提交于
      If a syscall is entered without TIF_SYSCALL_TRACE set, then it goes on
      the fast path.  It's then possible to have TIF_SYSCALL_TRACE added in
      the middle of the syscall, but ret_fast_syscall doesn't check this flag
      again.  This causes a ptrace syscall-exit-stop to be missed.
      
      For instance, from a PTRACE_EVENT_FORK reported during do_fork, the
      tracer might resume with PTRACE_SYSCALL, setting TIF_SYSCALL_TRACE.
      Now the completion of the fork should have a syscall-exit-stop.
      
      Russell King fixed this on arm by re-checking _TIF_SYSCALL_WORK in the
      fast exit path.  Do the same on arm64.
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NJosh Stone <jistone@redhat.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      04d7e098
  6. 05 6月, 2015 2 次提交
  7. 01 4月, 2015 1 次提交
  8. 27 1月, 2015 1 次提交
  9. 15 1月, 2015 1 次提交
  10. 28 11月, 2014 1 次提交
    • A
      arm64: ptrace: allow tracer to skip a system call · 1014c81d
      AKASHI Takahiro 提交于
      If tracer modifies a syscall number to -1, this traced system call should
      be skipped with a return value specified in x0.
      This patch implements this semantics.
      
      Please note:
      * syscall entry tracing and syscall exit tracing (ftrace tracepoint and
        audit) are always executed, if enabled, even when skipping a system call
        (that is, -1).
        In this way, we can avoid a potential bug where audit_syscall_entry()
        might be called without audit_syscall_exit() at the previous system call
        being called, that would cause OOPs in audit_syscall_entry().
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      [will: fixed up conflict with blr rework]
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      1014c81d
  11. 25 11月, 2014 1 次提交
  12. 14 11月, 2014 2 次提交
    • W
      arm64: entry: use ldp/stp instead of push/pop when saving/restoring regs · 63648dd2
      Will Deacon 提交于
      The push/pop instructions can be suboptimal when saving/restoring large
      amounts of data to/from the stack, for example on entry/exit from the
      kernel. This is because:
      
        (1) They act on descending addresses (i.e. the newly decremented sp),
            which may defeat some hardware prefetchers
      
        (2) They introduce an implicit dependency between each instruction, as
            the sp has to be updated in order to resolve the address of the
            next access.
      
      This patch removes the push/pop instructions from our kernel entry/exit
      macros in favour of ldp/stp plus offset.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      63648dd2
    • W
      arm64: entry: avoid writing lr explicitly for constructing return paths · d54e81f9
      Will Deacon 提交于
      Using an explicit adr instruction to set the link register to point at
      ret_fast_syscall/ret_to_user can defeat branch and return stack predictors.
      
      Instead, use the standard calling instructions (bl, blr) and have an
      unconditional branch as the following instruction.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d54e81f9
  13. 23 9月, 2014 1 次提交
  14. 10 7月, 2014 3 次提交
  15. 18 6月, 2014 1 次提交
  16. 12 5月, 2014 3 次提交
  17. 08 5月, 2014 1 次提交
    • A
      arm64: defer reloading a task's FPSIMD state to userland resume · 005f78cd
      Ard Biesheuvel 提交于
      If a task gets scheduled out and back in again and nothing has touched
      its FPSIMD state in the mean time, there is really no reason to reload
      it from memory. Similarly, repeated calls to kernel_neon_begin() and
      kernel_neon_end() will preserve and restore the FPSIMD state every time.
      
      This patch defers the FPSIMD state restore to the last possible moment,
      i.e., right before the task returns to userland. If a task does not return to
      userland at all (for any reason), the existing FPSIMD state is preserved
      and may be reused by the owning task if it gets scheduled in again on the
      same CPU.
      
      This patch adds two more functions to abstract away from straight FPSIMD
      register file saves and restores:
      - fpsimd_restore_current_state -> ensure current's FPSIMD state is loaded
      - fpsimd_flush_task_state -> invalidate live copies of a task's FPSIMD state
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      005f78cd
  18. 13 1月, 2014 1 次提交
  19. 20 12月, 2013 1 次提交
  20. 26 11月, 2013 1 次提交
    • M
      arm64: let the core code deal with preempt_count · 64681787
      Marc Zyngier 提交于
      Commit f27dde8d (sched: Add NEED_RESCHED to the preempt_count)
      introduced the use of bit 31 in preempt_count for obscure scheduling
      purposes.
      
      This causes interrupts taken from EL0 to hit the (open coded) BUG when
      this flag is flipped while handling the interrupt (we compare the
      values before and after, and kill the kernel if they are different).
      
      The fix is to stop messing with the preempt count entirely, as this
      is already being dealt with in the generic code (irq_enter/irq_exit).
      
      Tested on a dual A53 FPGA running cyclictest.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      64681787
  21. 05 11月, 2013 1 次提交
  22. 03 9月, 2013 1 次提交
  23. 22 8月, 2013 1 次提交
  24. 26 7月, 2013 1 次提交
  25. 31 5月, 2013 1 次提交
    • M
      arm64: treat unhandled compat el0 traps as undef · 381cc2b9
      Mark Rutland 提交于
      Currently, if a compat process reads or writes from/to a disabled
      cp15/cp14 register, the trap is not handled by the el0_sync_compat
      handler, and the kernel will head to bad_mode, where it will die(), and
      oops(). For 64 bit processes, disabled system register accesses are
      currently treated as unhandled instructions.
      
      This patch modifies entry.S to treat these unhandled traps as undefined
      instructions, sending a SIGILL to userspace. This gives processes a
      chance to handle this and stop using inaccessible registers, and
      prevents further issues in the kernel as a result of the die().
      Reported-by: NJohannes Jensen <Johannes.Jensen@arm.com>
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      381cc2b9
  26. 17 4月, 2013 1 次提交
  27. 14 2月, 2013 1 次提交
  28. 05 12月, 2012 1 次提交
  29. 23 10月, 2012 1 次提交
  30. 17 10月, 2012 3 次提交
  31. 11 10月, 2012 1 次提交
  32. 09 10月, 2012 1 次提交