1. 08 5月, 2014 2 次提交
    • 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
    • A
      arm64: add abstractions for FPSIMD state manipulation · c51f9269
      Ard Biesheuvel 提交于
      There are two tacit assumptions in the FPSIMD handling code that will no longer
      hold after the next patch that optimizes away some FPSIMD state restores:
      . the FPSIMD registers of this CPU contain the userland FPSIMD state of
        task 'current';
      . when switching to a task, its FPSIMD state will always be restored from
        memory.
      
      This patch adds the following functions to abstract away from straight FPSIMD
      register file saves and restores:
      - fpsimd_preserve_current_state -> ensure current's FPSIMD state is saved
      - fpsimd_update_current_state -> replace current's FPSIMD state
      
      Where necessary, the signal handling and fork code are updated to use the above
      wrappers instead of poking into the FPSIMD registers directly.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      c51f9269
  2. 14 2月, 2013 1 次提交
  3. 24 11月, 2012 2 次提交
    • W
      arm64: signal: return struct rt_sigframe from get_sigframe · b64e1c61
      Will Deacon 提交于
      We only have one type of frame (rt_sigframe) for arm64, so just return
      that type directly and dispense with the framesize argument, which is
      presumably a hangover from code copied from arch/arm/.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      b64e1c61
    • W
      arm64: signal: push the unwinding prologue on the signal stack · 304ef4e8
      Will Deacon 提交于
      To allow debuggers to unwind through signal frames, we create a fake
      stack unwinding prologue containing the link register and frame pointer
      of the interrupted context. The signal frame is then offset by 16 bytes
      to make room for the two saved registers which are pushed onto the frame
      of the *interrupted* context, rather than placed directly above the
      signal stack.
      
      This doesn't work when an alternative signal stack is set up for a SEGV
      handler, which is raised in response to RLIMIT_STACK being reached. In
      this case, we try to push the unwinding prologue onto the full stack and
      subsequently take a fault which we fail to resolve, causing setup_return
      to return -EFAULT and handle_signal to force_sigsegv on the current task.
      
      This patch fixes the problem by including the unwinding prologue as part
      of the rt_sigframe definition, which is populated during setup_sigframe,
      ensuring that it always ends up on the signal stack.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: <stable@vger.kernel.org>
      304ef4e8
  4. 17 9月, 2012 1 次提交