1. 01 6月, 2005 8 次提交
  2. 29 5月, 2005 2 次提交
  3. 21 5月, 2005 2 次提交
  4. 17 5月, 2005 1 次提交
  5. 07 5月, 2005 1 次提交
  6. 06 5月, 2005 4 次提交
    • M
      [PATCH] cyrix: eliminate bad section references · a27e951f
      maximilian attems 提交于
      Fix cyrix section references:
       convert __initdata to __devinitdata.
      
      Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 00000379
      R_386_32          .init.data
      Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 00000399
      R_386_32          .init.data
      Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 000003b3
      R_386_32          .init.data
      Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 000003b9
      R_386_32          .init.data
      Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 000003bf
      R_386_32          .init.data
      Signed-of-by: Nmaximilian attems <janitor@sternwelten.at>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a27e951f
    • P
      [PATCH] Kprobes: Incorrect handling of probes on ret/lret instruction · 0b9e2cac
      Prasanna S Panchamukhi 提交于
      Kprobes could not handle the insertion of a probe on the ret/lret
      instruction and used to oops after single stepping since kprobes was
      modifying eip/rip incorrectly.  Adjustment of eip/rip is not required after
      single stepping in case of ret/lret instruction, because eip/rip points to
      the correct location after execution of the ret/lret instruction.  This
      patch fixes the above problem.
      Signed-off-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0b9e2cac
    • P
      [PATCH] x86_64: make string func definition work as intended · 0c28130b
      Paolo 'Blaisorblade' Giarrusso 提交于
      In include/asm-x86_64/string.h there are such comments:
      
      /* Use C out of line version for memcmp */
      #define memcmp __builtin_memcmp
      int memcmp(const void * cs,const void * ct,size_t count);
      
      This would mean that if the compiler does not decide to use __builtin_memcmp,
      it emits a call to memcmp to be satisfied by the C out-of-line version in
      lib/string.c.  What happens is that after preprocessing, in lib/string.i you
      may find the definition of "__builtin_strcmp".
      
      Actually, by accident, in the object you will find the definition of strcmp
      and such (maybe a trick intended to redirect calls to __builtin_memcmp to the
      default memcmp when the definition is not expanded); however, this particular
      case is not a documented feature as far as I can see.
      
      Also, the EXPORT_SYMBOL does not work, so it's duplicated in the arch.
      
      I simply added some #undef to lib/string.c and removed the (now duplicated)
      exports in x86-64 and UML/x86_64 subarchs (the second ones are introduced by
      another patch I just posted for -mm).
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      CC: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0c28130b
    • A
      [PATCH] x86 stack initialisation fix · f48d9663
      Alexander Nyberg 提交于
      The recent change fix-crash-in-entrys-restore_all.patch
      
       	childregs->esp = esp;
      
       	p->thread.esp = (unsigned long) childregs;
      -	p->thread.esp0 = (unsigned long) (childregs+1);
      +	p->thread.esp0 = (unsigned long) (childregs+1) - 8;
      
       	p->thread.eip = (unsigned long) ret_from_fork;
      
      introduces an inconsistency between esp and esp0 before the task is run the
      first time.  esp0 is no longer the actual start of the stack, but 8 bytes
      off.
      
      This shows itself clearly in a scenario when a ptracer that is set to also
      ptrace eventual children traces program1 which then clones thread1.  Now
      the ptracer wants to modify the registers of thread1.  The x86 ptrace
      implementation bases it's knowledge about saved user-space registers upon
      p->thread.esp0.  But this will be a few bytes off causing certain writes to
      the kernel stack to overwrite a saved kernel function address making the
      kernel when actually running thread1 jump out into user-space.  Very
      spectacular.
      
      The testcase I've used is:
      /* start with strace -f ./a.out */
      #include <pthread.h>
      #include <stdio.h>
      
      void *do_thread(void *p)
      {
      	for (;;);
      }
      
      int main()
      {
      	pthread_t one;
      	pthread_create(&one, NULL, &do_thread, NULL);
      	for (;;);
      	return 0;
      }
      
      So, my solution is to instead of just adjusting esp0 that creates an
      inconsitent state I adjust where the user-space registers are saved with -8
      bytes.  This gives us the wanted extra bytes on the start of the stack and
      esp0 is now correct.  This solves the issues I saw from the original
      testcase from Mateusz Berezecki and has survived testing here.  I think
      this should go into -mm a round or two first however as there might be some
      cruft around depending on pt_regs lying on the start of the stack.  That
      however would have broken with the first change too!
      
      It's actually a 2-line diff but I had to move the comment of why the -8 bytes
      are there a few lines up. Thanks to Zwane for helping me with this.
      Signed-off-by: NAlexander Nyberg <alexn@telia.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f48d9663
  7. 01 5月, 2005 13 次提交
  8. 30 4月, 2005 1 次提交
    • L
      x86: make traps on 'iret' be debuggable in user space · a879cbbb
      Linus Torvalds 提交于
      This makes a trap on the 'iret' that returns us to user space
      cause a nice clean SIGSEGV, instead of just a hard (and silent)
      exit.
      
      That way a debugger can actually try to see what happened, and
      we also properly notify everybody who might be interested about
      us being gone.
      
      This loses the error code, but tells the debugger what happened
      with ILL_BADSTK in the siginfo.
      a879cbbb
  9. 29 4月, 2005 1 次提交
    • [AUDIT] Don't allow ptrace to fool auditing, log arch of audited syscalls. · 2fd6f58b
      提交于
      We were calling ptrace_notify() after auditing the syscall and arguments,
      but the debugger could have _changed_ them before the syscall was actually
      invoked. Reorder the calls to fix that.
      
      While we're touching ever call to audit_syscall_entry(), we also make it
      take an extra argument: the architecture of the syscall which was made,
      because some architectures allow more than one type of syscall.
      
      Also add an explicit success/failure flag to audit_syscall_exit(), for
      the benefit of architectures which return that in a condition register
      rather than only returning a single register.
      
      Change type of syscall return value to 'long' not 'int'.
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      2fd6f58b
  10. 22 4月, 2005 1 次提交
  11. 18 4月, 2005 1 次提交
  12. 17 4月, 2005 5 次提交