1. 30 1月, 2008 16 次提交
  2. 10 11月, 2007 2 次提交
    • C
      x86 - 32-bit ptrace emulation mishandles 6th arg · ecd744ee
      Chuck Ebbert 提交于
      [ jdike - Pushing Chuck's patch - see
      http://lkml.org/lkml/2005/9/16/261 for some history and a test
      program.  UML is also broken without this patch - its processes get
      SIGBUS from the corrupt 6th argument to mmap being interpretted as a
      file offset ]
      
      When the 32-bit vDSO is used to make a system call, the %ebp register for
      the 6th syscall arg has to be loaded from the user stack (where it's pushed
      by the vDSO user code).  The native i386 kernel always does this before
      stopping for syscall tracing, so %ebp can be seen and modified via ptrace
      to access the 6th syscall argument.  The x86-64 kernel fails to do this,
      presenting the stack address to ptrace instead.  This makes the %rbp value
      seen by 64-bit ptrace of a 32-bit process, and the %ebp value seen by a
      32-bit caller of ptrace, both differ from the native i386 behavior.
      
      This patch fixes the problem by putting the word loaded from the user stack
      into %rbp before calling syscall_trace_enter, and reloading the 6th syscall
      argument from there afterwards (so ptrace can change it).  This makes the
      behavior match that of i386 kernels.
      Original-Patch-By: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com>
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      ecd744ee
    • R
      x86_64: ia32 ptrace THREAD_AREA fix · fd181c72
      Roland McGrath 提交于
      The addr argument to PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA is
      not a magic constant.  It's derived from the segment register values being
      used, which are computed originally from the index used with set_thread_area.
      The value does not need to match what a native i386 kernel would accept.
      It needs to match the segment selectors that can actually be in use in this
      32-bit process.  The 64-bit ptrace support for PTRACE_GET_THREAD_AREA
      (normally used only on 32-bit processes) is correct, but the 32-bit emulation
      of ptrace is broken.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      fd181c72
  3. 20 10月, 2007 1 次提交
  4. 19 10月, 2007 1 次提交
  5. 18 10月, 2007 4 次提交
  6. 17 10月, 2007 3 次提交
    • A
      remove include/asm-*/ipc.h · cba4fbbf
      Adrian Bunk 提交于
      All asm/ipc.h files do only #include <asm-generic/ipc.h>.
      
      This patch therefore removes all include/asm-*/ipc.h files and moves the
      contents of include/asm-generic/ipc.h to include/linux/ipc.h.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cba4fbbf
    • N
      core_pattern: ignore RLIMIT_CORE if core_pattern is a pipe · 7dc0b22e
      Neil Horman 提交于
      For some time /proc/sys/kernel/core_pattern has been able to set its output
      destination as a pipe, allowing a user space helper to receive and
      intellegently process a core.  This infrastructure however has some
      shortcommings which can be enhanced.  Specifically:
      
      1) The coredump code in the kernel should ignore RLIMIT_CORE limitation
         when core_pattern is a pipe, since file system resources are not being
         consumed in this case, unless the user application wishes to save the core,
         at which point the app is restricted by usual file system limits and
         restrictions.
      
      2) The core_pattern code should be able to parse and pass options to the
         user space helper as an argv array.  The real core limit of the uid of the
         crashing proces should also be passable to the user space helper (since it
         is overridden to zero when called).
      
      3) Some miscellaneous bugs need to be cleaned up (specifically the
         recognition of a recursive core dump, should the user mode helper itself
         crash.  Also, the core dump code in the kernel should not wait for the user
         mode helper to exit, since the same context is responsible for writing to
         the pipe, and a read of the pipe by the user mode helper will result in a
         deadlock.
      
      This patch:
      
      Remove the check of RLIMIT_CORE if core_pattern is a pipe.  In the event that
      core_pattern is a pipe, the entire core will be fed to the user mode helper.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Cc: <martin.pitt@ubuntu.com>
      Cc: <wwoods@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7dc0b22e
    • M
      x86: replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define · 5b20cd80
      Mark Nelson 提交于
      Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump code which
      allows for more flexibility in the note type for the state of 'extended
      floating point' implementations in coredumps.  New note types can now be
      added with an appropriate #define.
      
      This does #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all
      current users so there's are no change in behaviour.
      
      This will let us use different note types on powerpc for the Altivec/VMX
      state that some PowerPC cpus have (G4, PPC970, POWER6) and for the SPE
      (signal processing extension) state that some embedded PowerPC cpus from
      Freescale have.
      Signed-off-by: NMark Nelson <markn@au1.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5b20cd80
  7. 11 10月, 2007 2 次提交