1. 09 10月, 2012 1 次提交
  2. 18 1月, 2012 1 次提交
    • E
      Audit: push audit success and retcode into arch ptrace.h · d7e7528b
      Eric Paris 提交于
      The audit system previously expected arches calling to audit_syscall_exit to
      supply as arguments if the syscall was a success and what the return code was.
      Audit also provides a helper AUDITSC_RESULT which was supposed to simplify things
      by converting from negative retcodes to an audit internal magic value stating
      success or failure.  This helper was wrong and could indicate that a valid
      pointer returned to userspace was a failed syscall.  The fix is to fix the
      layering foolishness.  We now pass audit_syscall_exit a struct pt_reg and it
      in turns calls back into arch code to collect the return value and to
      determine if the syscall was a success or failure.  We also define a generic
      is_syscall_success() macro which determines success/failure based on if the
      value is < -MAX_ERRNO.  This works for arches like x86 which do not use a
      separate mechanism to indicate syscall failure.
      
      We make both the is_syscall_success() and regs_return_value() static inlines
      instead of macros.  The reason is because the audit function must take a void*
      for the regs.  (uml calls theirs struct uml_pt_regs instead of just struct
      pt_regs so audit_syscall_exit can't take a struct pt_regs).  Since the audit
      function takes a void* we need to use static inlines to cast it back to the
      arch correct structure to dereference it.
      
      The other major change is that on some arches, like ia64, MIPS and ppc, we
      change regs_return_value() to give us the negative value on syscall failure.
      THE only other user of this macro, kretprobe_example.c, won't notice and it
      makes the value signed consistently for the audit functions across all archs.
      
      In arch/sh/kernel/ptrace_64.c I see that we were using regs[9] in the old
      audit code as the return value.  But the ptrace_64.h code defined the macro
      regs_return_value() as regs[3].  I have no idea which one is correct, but this
      patch now uses the regs_return_value() function, so it now uses regs[3].
      
      For powerpc we previously used regs->result but now use the
      regs_return_value() function which uses regs->gprs[3].  regs->gprs[3] is
      always positive so the regs_return_value(), much like ia64 makes it negative
      before calling the audit code when appropriate.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: H. Peter Anvin <hpa@zytor.com> [for x86 portion]
      Acked-by: Tony Luck <tony.luck@intel.com> [for ia64]
      Acked-by: Richard Weinberger <richard@nod.at> [for uml]
      Acked-by: David S. Miller <davem@davemloft.net> [for sparc]
      Acked-by: Ralf Baechle <ralf@linux-mips.org> [for mips]
      Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [for ppc]
      d7e7528b
  3. 27 7月, 2011 1 次提交
  4. 13 3月, 2010 1 次提交
    • C
      ptrace: move user_enable_single_step & co prototypes to linux/ptrace.h · dacbe41f
      Christoph Hellwig 提交于
      While in theory user_enable_single_step/user_disable_single_step/
      user_enable_blockstep could also be provided as an inline or macro there's
      no good reason to do so, and having the prototype in one places keeps code
      size and confusion down.
      
      Roland said:
      
        The original thought there was that user_enable_single_step() et al
        might well be only an instruction or three on a sane machine (as if we
        have any of those!), and since there is only one call site inlining
        would be beneficial.  But I agree that there is no strong reason to care
        about inlining it.
      
        As to the arch changes, there is only one thought I'd add to the
        record.  It was always my thinking that for an arch where
        PTRACE_SINGLESTEP does text-modifying breakpoint insertion,
        user_enable_single_step() should not be provided.  That is,
        arch_has_single_step()=>true means that there is an arch facility with
        "pure" semantics that does not have any unexpected side effects.
        Inserting a breakpoint might do very unexpected strange things in
        multi-threaded situations.  Aside from that, it is a peculiar side
        effect that user_{enable,disable}_single_step() should cause COW
        de-sharing of text pages and so forth.  For PTRACE_SINGLESTEP, all these
        peculiarities are the status quo ante for that arch, so having
        arch_ptrace() itself do those is one thing.  But for building other
        things in the future, it is nicer to have a uniform "pure" semantics
        that arch-independent code can expect.
      
        OTOH, all such arch issues are really up to the arch maintainer.  As
        of today, there is nothing but ptrace using user_enable_single_step() et
        al so it's a distinction without a practical difference.  If/when there
        are other facilities that use user_enable_single_step() and might care,
        the affected arch's can revisit the question when someone cares about
        the quality of the arch support for said new facility.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Roland McGrath <roland@redhat.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dacbe41f
  5. 01 12月, 2008 1 次提交
  6. 07 10月, 2008 2 次提交
  7. 02 8月, 2008 1 次提交
    • T
      [IA64] Move include/asm-ia64 to arch/ia64/include/asm · 7f30491c
      Tony Luck 提交于
      After moving the the include files there were a few clean-ups:
      
      1) Some files used #include <asm-ia64/xyz.h>, changed to <asm/xyz.h>
      
      2) Some comments alerted maintainers to look at various header files to
      make matching updates if certain code were to be changed. Updated these
      comments to use the new include paths.
      
      3) Some header files mentioned their own names in initial comments. Just
      deleted these self references.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      7f30491c
  8. 28 5月, 2008 1 次提交
    • T
      [IA64] Workaround for RSE issue · 4dcc29e1
      Tony Luck 提交于
      Problem: An application violating the architectural rules regarding
      operation dependencies and having specific Register Stack Engine (RSE)
      state at the time of the violation, may result in an illegal operation
      fault and invalid RSE state.  Such faults may initiate a cascade of
      repeated illegal operation faults within OS interruption handlers.
      The specific behavior is OS dependent.
      
      Implication: An application causing an illegal operation fault with
      specific RSE state may result in a series of illegal operation faults
      and an eventual OS stack overflow condition.
      
      Workaround: OS interruption handlers that switch to kernel backing
      store implement a check for invalid RSE state to avoid the series
      of illegal operation faults.
      
      The core of the workaround is the RSE_WORKAROUND code sequence
      inserted into each invocation of the SAVE_MIN_WITH_COVER and
      SAVE_MIN_WITH_COVER_R19 macros.  This sequence includes hard-coded
      constants that depend on the number of stacked physical registers
      being 96.  The rest of this patch consists of code to disable this
      workaround should this not be the case (with the presumption that
      if a future Itanium processor increases the number of registers, it
      would also remove the need for this patch).
      
      Move the start of the RBS up to a mod32 boundary to avoid some
      corner cases.
      
      The dispatch_illegal_op_fault code outgrew the spot it was
      squatting in when built with this patch and CONFIG_VIRT_CPU_ACCOUNTING=y
      Move it out to the end of the ivt.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      4dcc29e1
  9. 06 3月, 2008 2 次提交
  10. 09 2月, 2008 2 次提交
  11. 02 10月, 2006 1 次提交
  12. 17 9月, 2006 1 次提交
  13. 26 4月, 2006 1 次提交
  14. 13 1月, 2006 1 次提交
  15. 07 11月, 2005 1 次提交
  16. 13 9月, 2005 1 次提交
  17. 12 9月, 2005 1 次提交
  18. 10 9月, 2005 1 次提交
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4