“a693864e884800e6c1958898db63ac41eb6753f7”上不存在“...actsamsprocessmultiinstancetest/BUILD.gn”
  1. 23 5月, 2016 2 次提交
  2. 31 3月, 2016 1 次提交
    • H
      parisc: Fix and enable seccomp filter support · 910cd32e
      Helge Deller 提交于
      The seccomp filter support requires careful handling of task registers.  This
      includes reloading of the return value (%r28) and proper syscall exit if
      secure_computing() returned -1.
      
      Additionally we need to sign-extend the syscall number from signed 32bit to
      signed 64bit in do_syscall_trace_enter() since the ptrace interface only allows
      storing 32bit values in compat mode.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org # v4.5
      910cd32e
  3. 02 3月, 2016 1 次提交
    • H
      parisc: Fix ptrace syscall number and return value modification · 98e8b6c9
      Helge Deller 提交于
      Mike Frysinger reported that his ptrace testcase showed strange
      behaviour on parisc: It was not possible to avoid a syscall and the
      return value of a syscall couldn't be changed.
      
      To modify a syscall number, we were missing to save the new syscall
      number to gr20 which is then picked up later in assembly again.
      
      The effect that the return value couldn't be changed is a side-effect of
      another bug in the assembly code. When a process is ptraced, userspace
      expects each syscall to report entrance and exit of a syscall.  If a
      syscall number was given which doesn't exist, we jumped to the normal
      syscall exit code instead of informing userspace that the (non-existant)
      syscall exits. This unexpected behaviour confuses userspace and thus the
      bug was misinterpreted as if we can't change the return value.
      
      This patch fixes both problems and was tested on 64bit kernel with
      32bit userspace.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: stable@vger.kernel.org  # v4.0+
      Tested-by: NMike Frysinger <vapier@gentoo.org>
      98e8b6c9
  4. 24 9月, 2014 1 次提交
    • E
      ARCH: AUDIT: audit_syscall_entry() should not require the arch · 91397401
      Eric Paris 提交于
      We have a function where the arch can be queried, syscall_get_arch().
      So rather than have every single piece of arch specific code use and/or
      duplicate syscall_get_arch(), just have the audit code use the
      syscall_get_arch() code.
      Based-on-patch-by: NRichard Briggs <rgb@redhat.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-ia64@vger.kernel.org
      Cc: microblaze-uclinux@itee.uq.edu.au
      Cc: linux-mips@linux-mips.org
      Cc: linux@lists.openrisc.net
      Cc: linux-parisc@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-s390@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: sparclinux@vger.kernel.org
      Cc: user-mode-linux-devel@lists.sourceforge.net
      Cc: linux-xtensa@linux-xtensa.org
      Cc: x86@kernel.org
      91397401
  5. 22 9月, 2014 1 次提交
  6. 27 8月, 2014 1 次提交
  7. 08 11月, 2013 1 次提交
  8. 08 1月, 2013 1 次提交
    • J
      parisc: improve ptrace support for gdb single-step · 34360f08
      John David Anglin 提交于
      Various GCC tests use gdb to simulate a multithreaded application. Many of
      these tests have been failing on parisc linux.
      
      GCC does this by using gdb to single-step the application, then gdb is used to
      call other test specific code. Where this fails is when the application is
      stepped into the delay slot of a taken branch. This sets the PSW B bit. When
      the test specific code is executed, this usually clears the PSW B bit.
      Currently, gdb is not allowed to set the B bit. So, the code falls through what
      should be a taken branch.
      
      The attached patch adds the PSW B bit to the set of bits that gdb is allowed to
      set. In order to set the B bit, the trace system call must return using an
      interrupt restore. The patch also modifies this code to use the saved IAOQ
      values when they are saved by a ptrace syscall or interruption.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      34360f08
  9. 29 3月, 2012 1 次提交
  10. 28 10月, 2010 2 次提交
  11. 28 9月, 2009 3 次提交
  12. 21 11月, 2008 1 次提交
    • H
      parisc: fix bug in compat_arch_ptrace · ed79b86d
      Helge Deller 提交于
      Commit 81e192d6 ("parisc: convert to
      generic compat_sys_ptrace") introduced a bug which segfaults the parisc
      64bit kernel when stracing 32bit applications:
      
        Kernel Fault: Code=15 regs=00000000bafa42b0 (Addr=00000001baf5ab57)
             YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
        PSW: 00001000000001101111111100001011 Tainted: G        W
        r00-03  000000ff0806ff0b 000000004068edc0 00000000401203f8 00000000fb3e2508
        r04-07  0000000040686dc0 00000000baf5a800 fffffffffffffffc fffffffffb3e2508
        r08-11  00000000baf5a800 000000000004b068 00000000000402b0 0000000000040d68
        r12-15  0000000000042a9c 0000000000040a9c 0000000000040d60 0000000000042e9c
        r16-19  000000000004b060 000000000004b058 0000000000042d9c ffffffffffffffff
        r20-23  000000000800000b 0000000000000000 000000000800000b fffffffffb3e2508
        r24-27  00000000fffffffc 0000000000000003 00000000fffffffc 0000000040686dc0
        r28-31  00000001baf5a7ff 00000000bafa4280 00000000bafa42b0 00000000000001d7
        sr00-03  0000000000fca000 0000000000000000 0000000000000000 0000000000fca000
        sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      
        IASQ: 0000000000000000 0000000000000000 IAOQ: 0000000040120400 0000000040120404
         IIR: 4b9a06b0    ISR: 0000000000000000  IOR: 00000001baf5ab57
         CPU:        0   CR30: 00000000bafa4000 CR31: 00000000d22344e0
         ORIG_R28: 00000000fb3e2248
         IAOQ[0]: compat_arch_ptrace+0xb8/0x160
         IAOQ[1]: compat_arch_ptrace+0xbc/0x160
         RP(r2): compat_arch_ptrace+0xb0/0x160
        Backtrace:
         [<00000000401612ac>] compat_sys_ptrace+0x15c/0x180
         [<0000000040104ef8>] syscall_exit+0x0/0x14
      
      The problem is that compat_arch_ptrace() enters with an addr value of
      type compat_ulong_t and calls translate_usr_offset() to translate the
      address offset into a struct pt_regs offset like this:
      
      	addr = translate_usr_offset(addr)
      
      this means that any return value of translate_usr_offset() is stored
      back as compat_ulong_t type into the addr variable.
      
      But since translate_usr_offset() returns -1 for invalid offsets, addr
      can now get the value 0xffffffff which then fails the next return-value
      sanity check and thus the kernel tries to access invalid memory:
      
      	if (addr < 0)
      		break;
      
      Fix this bug by modifying translate_usr_offset() to take and return
      values of type compat_ulong_t, and by returning the value
      "sizeof(struct pt_regs)" as an error indicator.
      
      Additionally change the sanity check to check for return values
      for >= sizeof(struct pt_regs).
      
      This patch survived my compile and run-tests.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ed79b86d
  13. 18 10月, 2008 1 次提交
  14. 17 10月, 2007 1 次提交
  15. 18 7月, 2007 1 次提交
  16. 09 5月, 2007 1 次提交
  17. 17 2月, 2007 1 次提交
  18. 28 6月, 2006 1 次提交
  19. 23 1月, 2006 1 次提交
    • K
      [PARISC] Arch-specific compat signals · f671c45d
      Kyle McMartin 提交于
      Add enough arch-specific compat signals code to enable parisc64
      to compile and boot out of the mainline tree. There are likely still
      many dragons here, but this is a start to squashing the last
      big difference between the mainline tree and the parisc-linux tree.
      The remaining bugs can be squashed as they come up.
      Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
      f671c45d
  20. 18 11月, 2005 1 次提交
  21. 07 11月, 2005 1 次提交
  22. 31 10月, 2005 1 次提交
  23. 10 9月, 2005 1 次提交
  24. 01 5月, 2005 1 次提交
  25. 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