1. 24 2月, 2013 1 次提交
  2. 23 2月, 2013 1 次提交
  3. 14 2月, 2013 1 次提交
  4. 08 2月, 2013 1 次提交
  5. 04 2月, 2013 8 次提交
  6. 31 1月, 2013 1 次提交
  7. 20 12月, 2012 2 次提交
  8. 29 11月, 2012 2 次提交
  9. 01 10月, 2012 1 次提交
  10. 22 9月, 2012 2 次提交
  11. 19 9月, 2012 1 次提交
    • S
      x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels · 72a671ce
      Suresh Siddha 提交于
      Currently for x86 and x86_32 binaries, fpstate in the user sigframe is copied
      to/from the fpstate in the task struct.
      
      And in the case of signal delivery for x86_64 binaries, if the fpstate is live
      in the CPU registers, then the live state is copied directly to the user
      sigframe. Otherwise  fpstate in the task struct is copied to the user sigframe.
      During restore, fpstate in the user sigframe is restored directly to the live
      CPU registers.
      
      Historically, different code paths led to different bugs. For example,
      x86_64 code path was not preemption safe till recently. Also there is lot
      of code duplication for support of new features like xsave etc.
      
      Unify signal handling code paths for x86 and x86_64 kernels.
      
      New strategy is as follows:
      
      Signal delivery: Both for 32/64-bit frames, align the core math frame area to
      64bytes as needed by xsave (this where the main fpu/extended state gets copied
      to and excludes the legacy compatibility fsave header for the 32-bit [f]xsave
      frames). If the state is live, copy the register state directly to the user
      frame. If not live, copy the state in the thread struct to the user frame. And
      for 32-bit [f]xsave frames, construct the fsave header separately before
      the actual [f]xsave area.
      
      Signal return: As the 32-bit frames with [f]xstate has an additional
      'fsave' header, copy everything back from the user sigframe to the
      fpstate in the task structure and reconstruct the fxstate from the 'fsave'
      header (Also user passed pointers may not be correctly aligned for
      any attempt to directly restore any partial state). At the next fpstate usage,
      everything will be restored to the live CPU registers.
      For all the 64-bit frames and the 32-bit fsave frame, restore the state from
      the user sigframe directly to the live CPU registers. 64-bit signals always
      restored the math frame directly, so we can expect the math frame pointer
      to be correctly aligned. For 32-bit fsave frames, there are no alignment
      requirements, so we can restore the state directly.
      
      "lat_sig catch" microbenchmark numbers (for x86, x86_64, x86_32 binaries) are
      with in the noise range with this change.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1343171129-2747-4-git-send-email-suresh.b.siddha@intel.com
      [ Merged in compilation fix ]
      Link: http://lkml.kernel.org/r/1344544736.8326.17.camel@sbsiddha-desk.sc.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      72a671ce
  12. 05 9月, 2012 2 次提交
  13. 15 6月, 2012 1 次提交
  14. 02 6月, 2012 1 次提交
  15. 22 5月, 2012 1 次提交
  16. 16 5月, 2012 1 次提交
  17. 08 5月, 2012 1 次提交
  18. 07 5月, 2012 1 次提交
  19. 21 4月, 2012 4 次提交
  20. 14 4月, 2012 1 次提交
    • W
      signal, x86: add SIGSYS info and make it synchronous. · a0727e8c
      Will Drewry 提交于
      This change enables SIGSYS, defines _sigfields._sigsys, and adds
      x86 (compat) arch support.  _sigsys defines fields which allow
      a signal handler to receive the triggering system call number,
      the relevant AUDIT_ARCH_* value for that number, and the address
      of the callsite.
      
      SIGSYS is added to the SYNCHRONOUS_MASK because it is desirable for it
      to have setup_frame() called for it. The goal is to ensure that
      ucontext_t reflects the machine state from the time-of-syscall and not
      from another signal handler.
      
      The first consumer of SIGSYS would be seccomp filter.  In particular,
      a filter program could specify a new return value, SECCOMP_RET_TRAP,
      which would result in the system call being denied and the calling
      thread signaled.  This also means that implementing arch-specific
      support can be dependent upon HAVE_ARCH_SECCOMP_FILTER.
      Suggested-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NWill Drewry <wad@chromium.org>
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Reviewed-by: NH. Peter Anvin <hpa@zytor.com>
      Acked-by: NEric Paris <eparis@redhat.com>
      
      v18: - added acked by, rebase
      v17: - rebase and reviewed-by addition
      v14: - rebase/nochanges
      v13: - rebase on to 88ebdda6
      v12: - reworded changelog (oleg@redhat.com)
      v11: - fix dropped words in the change description
           - added fallback copy_siginfo support.
           - added __ARCH_SIGSYS define to allow stepped arch support.
      v10: - first version based on suggestion
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      a0727e8c
  21. 29 3月, 2012 1 次提交
  22. 21 3月, 2012 2 次提交
  23. 14 3月, 2012 1 次提交
  24. 13 3月, 2012 1 次提交
  25. 06 3月, 2012 1 次提交
    • H
      x32: Switch to a 64-bit clock_t · e7084fd5
      H. Peter Anvin 提交于
      clock_t is used mainly to give the number of jiffies a certain process
      has burned.  It is entirely feasible for a long-running process to
      consume more than 2^32 jiffies especially in a multiprocess system.
      As such, switch to a 64-bit clock_t for x32, just as we already
      switched to a 64-bit time_t.
      
      clock_t is only used in a handful of places, and as such it is really
      not a very significant change.  The one that has the biggest impact is
      in struct siginfo, but since the *size* of struct siginfo doesn't
      change (it is padded to the hilt) it is fairly easy to make this a
      localized change.
      
      This also gets rid of sys_x32_times, however since this is a pretty
      late change don't compactify the system call numbers; we can reuse
      system call slot 521 next time we need an x32 system call.
      Reported-by: NGregory M. Lueck <gregory.m.lueck@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: H. J. Lu <hjl.tools@gmail.com>
      Link: http://lkml.kernel.org/r/1329696488-16970-1-git-send-email-hpa@zytor.com
      e7084fd5