1. 10 Nov, 2007 5 commits
    • Rolf Eike Beer's avatar
      Add missing "\n" to log message · cee687ce
      Rolf Eike Beer authored
      Signed-off-by: default avatarRolf Eike Beer <eike-kernel@sf-tec.de>
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      cee687ce
    • Chuck Ebbert's avatar
      x86 - 32-bit ptrace emulation mishandles 6th arg · ecd744ee
      Chuck Ebbert authored
      [ 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: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarChuck Ebbert <76306.1226@compuserve.com>
      Signed-off-by: default avatarJeff Dike <jdike@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      ecd744ee
    • Roland McGrath's avatar
      x86_64: ia32 ptrace THREAD_AREA fix · fd181c72
      Roland McGrath authored
      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: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      fd181c72
    • Randy Dunlap's avatar
      voyager: use struct instead of PARAM · 1a0c3ea6
      Randy Dunlap authored
      Use struct boot_params instead of PARAM + 0xoffsets.
      Fixes one of many Voyager build problems.
      
      arch/x86/kernel/setup_32.c:543: error: 'PARAM' undeclared (first use in this function)
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      1a0c3ea6
    • David Miller's avatar
      [FUTEX] Fix address computation in compat code. · 3c5fd9c7
      David Miller authored
      compat_exit_robust_list() computes a pointer to the
      futex entry in userspace as follows:
      
      	(void __user *)entry + futex_offset
      
      'entry' is a 'struct robust_list __user *', and
      'futex_offset' is a 'compat_long_t' (typically a 's32').
      
      Things explode if the 32-bit sign bit is set in futex_offset.
      
      Type promotion sign extends futex_offset to a 64-bit value before
      adding it to 'entry'.
      
      This triggered a problem on sparc64 running 32-bit applications which
      would lock up a cpu looping forever in the fault handling for the
      userspace load in handle_futex_death().
      
      Compat userspace runs with address masking (wherein the cpu zeros out
      the top 32-bits of every effective address given to a memory operation
      instruction) so the sparc64 fault handler accounts for this by
      zero'ing out the top 32-bits of the fault address too.
      
      Since the kernel properly uses the compat_uptr interfaces, kernel side
      accesses to compat userspace work too since they will only use
      addresses with the top 32-bit clear.
      
      Because of this compat futex layer bug we get into the following loop
      when executing the get_user() load near the top of handle_futex_death():
      
      1) load from address '0xfffffffff7f16bd8', FAULT
      2) fault handler clears upper 32-bits, processes fault
         for address '0xf7f16bd8' which succeeds
      3) goto #1
      
      I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
      for their tireless efforts helping me track down this bug.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3c5fd9c7
  2. 09 Nov, 2007 35 commits