1. 27 8月, 2015 1 次提交
    • A
      arm64: flush FP/SIMD state correctly after execve() · 674c242c
      Ard Biesheuvel 提交于
      When a task calls execve(), its FP/SIMD state is flushed so that
      none of the original program state is observeable by the incoming
      program.
      
      However, since this flushing consists of setting the in-memory copy
      of the FP/SIMD state to all zeroes, the CPU field is set to CPU 0 as
      well, which indicates to the lazy FP/SIMD preserve/restore code that
      the FP/SIMD state does not need to be reread from memory if the task
      is scheduled again on CPU 0 without any other tasks having entered
      userland (or used the FP/SIMD in kernel mode) on the same CPU in the
      mean time. If this happens, the FP/SIMD state of the old program will
      still be present in the registers when the new program starts.
      
      So set the CPU field to the invalid value of NR_CPUS when performing
      the flush, by calling fpsimd_flush_task_state().
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NChunyan Zhang <chunyan.zhang@spreadtrum.com>
      Reported-by: NJanet Liu <janet.liu@spreadtrum.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      674c242c
  2. 12 6月, 2015 1 次提交
  3. 01 9月, 2014 1 次提交
  4. 08 5月, 2014 3 次提交
    • A
      arm64: add support for kernel mode NEON in interrupt context · 190f1ca8
      Ard Biesheuvel 提交于
      This patch modifies kernel_neon_begin() and kernel_neon_end(), so
      they may be called from any context. To address the case where only
      a couple of registers are needed, kernel_neon_begin_partial(u32) is
      introduced which takes as a parameter the number of bottom 'n' NEON
      q-registers required. To mark the end of such a partial section, the
      regular kernel_neon_end() should be used.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      190f1ca8
    • 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
  5. 17 12月, 2013 1 次提交
  6. 28 9月, 2013 1 次提交
  7. 20 8月, 2013 1 次提交
  8. 17 9月, 2012 1 次提交