An error occurred fetching the project authors.
  1. 28 Oct, 2005 1 commit
  2. 27 Oct, 2005 1 commit
    • Cliff Wickman's avatar
      [IA64] ptrace - find memory sharers on children list · 4ac0068f
      Cliff Wickman authored
      In arch/ia64/kernel/ptrace.c there is a test for a peek or poke of a
      register image (in register backing storage).
      The test can be unnecessarily long (and occurs while holding the tasklist_lock).
      Especially long on a large system with thousands of active tasks.
      
      The ptrace caller (presumably a debugger) specifies the pid of
      its target and an address to peek or poke.  But the debugger could be
      attached to several tasks.
      The idea of find_thread_for_addr() is to find whether the target address
      is in the RBS for any of those tasks.
      
      Currently it searches the thread-list of the target pid.  If that search
      does not find a match, and the shared mm-struct's user count indicates
      that there are other tasks sharing this address space (a rare occurrence),
      a search is made of all the tasks in the system.
      
      Another approach can drastically shorten this procedure.
      It depends upon the fact that in order to peek or poke from/to any task,
      the debugger must first attach to that task.  And when it does, the
      attached task is made a child of the debugger (is chained to its children list).
      
      Therefore we can search just the debugger's children list.
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      4ac0068f
  3. 21 Jun, 2005 1 commit
  4. 08 Jun, 2005 1 commit
    • Peter Chubb's avatar
      [PATCH] ia64: fix floating-point preemption problem · 05062d96
      Peter Chubb authored
      There've been reports of problems with CONFIG_PREEMPT=y and the high
      floating point partition.  This is caused by the possibility of preemption
      and rescheduling on a different processor while saving or restioirng the
      high partition.
      
      The only places where the FPU state is touched are in ptrace, in
      switch_to(), and where handling a floating-point exception.  In switch_to()
      preemption is off.  So it's only in trap.c and ptrace.c that we need to
      prevent preemption.
      
      Here is a patch that adds commentary to make the conditions clear, and adds
      appropriate preempt_{en,dis}able() calls to make it so.  In trap.c I use
      preempt_enable_no_resched(), as we're about to return to user space where
      the preemption flag will be checked anyway.
      Signed-off-by: default avatarPeter Chubb <peterc@gelato.unsw.edu.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      05062d96
  5. 17 May, 2005 2 commits
  6. 01 May, 2005 1 commit
  7. 29 Apr, 2005 1 commit
    • 's avatar
      [AUDIT] Don't allow ptrace to fool auditing, log arch of audited syscalls. · 2fd6f58b
      authored
      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: default avatarDavid Woodhouse <dwmw2@infradead.org>
      2fd6f58b
  8. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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