1. 09 1月, 2006 1 次提交
  2. 29 10月, 2005 1 次提交
  3. 28 10月, 2005 1 次提交
    • C
      [IA64] ptrace - find memory sharers on children list · 4ac0068f
      Cliff Wickman 提交于
      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: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      4ac0068f
  4. 22 6月, 2005 1 次提交
  5. 09 6月, 2005 1 次提交
    • P
      [PATCH] ia64: fix floating-point preemption problem · 05062d96
      Peter Chubb 提交于
      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: NPeter Chubb <peterc@gelato.unsw.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      05062d96
  6. 18 5月, 2005 2 次提交
  7. 01 5月, 2005 1 次提交
  8. 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
  9. 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