1. 27 9月, 2006 1 次提交
  2. 04 7月, 2006 1 次提交
  3. 27 6月, 2006 2 次提交
    • O
      [PATCH] coredump: kill ptrace related stuff · d5f70c00
      Oleg Nesterov 提交于
      With this patch zap_process() sets SIGNAL_GROUP_EXIT while sending SIGKILL to
      the thread group.  This means that a TASK_TRACED task
      
      	1. Will be awakened by signal_wake_up(1)
      
      	2. Can't sleep again via ptrace_notify()
      
      	3. Can't go to do_signal_stop() after return
      	   from ptrace_stop() in get_signal_to_deliver()
      
      So we can remove all ptrace related stuff from coredump path.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d5f70c00
    • E
      [PATCH] proc: Cleanup proc_fd_access_allowed · df26c40e
      Eric W. Biederman 提交于
      In process of getting proc_fd_access_allowed to work it has developed a few
      warts.  In particular the special case that always allows introspection and
      the special case to allow inspection of kernel threads.
      
      The special case for introspection is needed for /proc/self/mem.
      
      The special case for kernel threads really should be overridable
      by security modules.
      
      So consolidate these checks into ptrace.c:may_attach().
      
      The check to always allow introspection is trivial.
      
      The check to allow access to kernel threads, and zombies is a little
      trickier.  mem_read and mem_write already verify an mm exists so it isn't
      needed twice.  proc_fd_access_allowed only doesn't want a check to verify
      task->mm exits, s it prevents all access to kernel threads.  So just move
      the task->mm check into ptrace_attach where it is needed for practical
      reasons.
      
      I did a quick audit and none of the security modules in the kernel seem to
      care if they are passed a task without an mm into security_ptrace.  So the
      above move should be safe and it allows security modules to come up with
      more restrictive policy.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      df26c40e
  4. 12 5月, 2006 1 次提交
    • L
      ptrace_attach: fix possible deadlock schenario with irqs · f358166a
      Linus Torvalds 提交于
      Eric Biederman points out that we can't take the task_lock while holding
      tasklist_lock for writing, because another CPU that holds the task lock
      might take an interrupt that then tries to take tasklist_lock for writing.
      
      Which would be a nasty deadlock, with one CPU spinning forever in an
      interrupt handler (although admittedly you need to really work at
      triggering it ;)
      
      Since the ptrace_attach() code is special and very unusual, just make it
      be extra careful, and use trylock+repeat to avoid the possible deadlock.
      
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f358166a
  5. 08 5月, 2006 1 次提交
    • L
      Fix ptrace_attach()/ptrace_traceme()/de_thread() race · f5b40e36
      Linus Torvalds 提交于
      This holds the task lock (and, for ptrace_attach, the tasklist_lock)
      over the actual attach event, which closes a race between attacking to a
      thread that is either doing a PTRACE_TRACEME or getting de-threaded.
      
      Thanks to Oleg Nesterov for reminding me about this, and Chris Wright
      for noticing a lost return value in my first version.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f5b40e36
  6. 14 4月, 2006 1 次提交
  7. 02 4月, 2006 1 次提交
  8. 29 3月, 2006 1 次提交
  9. 16 2月, 2006 1 次提交
  10. 15 2月, 2006 1 次提交
  11. 12 1月, 2006 1 次提交
  12. 09 1月, 2006 1 次提交
  13. 30 11月, 2005 1 次提交
  14. 14 11月, 2005 1 次提交
  15. 10 11月, 2005 1 次提交
  16. 07 11月, 2005 1 次提交
  17. 31 10月, 2005 1 次提交
    • A
      [PATCH] ptrace/coredump/exit_group deadlock · 30e0fca6
      Andrea Arcangeli 提交于
      I could seldom reproduce a deadlock with a task not killable in T state
      (TASK_STOPPED, not TASK_TRACED) by attaching a NPTL threaded program to
      gdb, by segfaulting the task and triggering a core dump while some other
      task is executing exit_group and while one task is in ptrace_attached
      TASK_STOPPED state (not TASK_TRACED yet).  This originated from a gdb
      bugreport (the fact gdb was segfaulting the task wasn't a kernel bug), but
      I just incidentally noticed the gdb bug triggered a real kernel bug as
      well.
      
      Most threads hangs in exit_mm because the core_dumping is still going, the
      core dumping hangs because the stopped task doesn't exit, the stopped task
      can't wakeup because it has SIGNAL_GROUP_EXIT set, hence the deadlock.
      
      To me it seems that the problem is that the force_sig_specific(SIGKILL) in
      zap_threads is a noop if the task has PF_PTRACED set (like in this case
      because gdb is attached).  The __ptrace_unlink does nothing because the
      signal->flags is set to SIGNAL_GROUP_EXIT|SIGNAL_STOP_DEQUEUED (verified).
      
      The above info also shows that the stopped task hit a race and got the stop
      signal (presumably by the ptrace_attach, only the attach, state is still
      TASK_STOPPED and gdb hangs waiting the core before it can set it to
      TASK_TRACED) after one of the thread invoked the core dump (it's the core
      dump that sets signal->flags to SIGNAL_GROUP_EXIT).
      
      So beside the fact nobody would wakeup the task in __ptrace_unlink (the
      state is _not_ TASK_TRACED), there's a secondary problem in the signal
      handling code, where a task should ignore the ptrace-sigstops as long as
      SIGNAL_GROUP_EXIT is set (or the wakeup in __ptrace_unlink path wouldn't be
      enough).
      
      So I attempted to make this patch that seems to fix the problem.  There
      were various ways to fix it, perhaps you prefer a different one, I just
      opted to the one that looked safer to me.
      
      I also removed the clearing of the stopped bits from the zap_other_threads
      (zap_other_threads was safe unlike zap_threads).  I don't like useless
      code, this whole NPTL signal/ptrace thing is already unreadable enough and
      full of corner cases without confusing useless code into it to make it even
      less readable.  And if this code is really needed, then you may want to
      explain why it's not being done in the other paths that sets
      SIGNAL_GROUP_EXIT at least.
      
      Even after this patch I still wonder who serializes the read of
      p->ptrace in zap_threads.
      
      Patch is called ptrace-core_dump-exit_group-deadlock-1.
      
      This was the trace I've got:
      
      test          T ffff81003e8118c0     0 14305      1         14311 14309 (NOTLB)
      ffff810058ccdde8 0000000000000082 000001f4000037e1 ffff810000000013
             00000000000000f8 ffff81003e811b00 ffff81003e8118c0 ffff810011362100
             0000000000000012 ffff810017ca4180
      Call Trace:<ffffffff801317ed>{try_to_wake_up+893} <ffffffff80141677>{finish_stop+87}
             <ffffffff8014367f>{get_signal_to_deliver+1359} <ffffffff8010d3ad>{do_signal+157}
             <ffffffff8013deee>{ptrace_check_attach+222} <ffffffff80111575>{sys_ptrace+2293}
             <ffffffff80131810>{default_wake_function+0} <ffffffff80196399>{sys_ioctl+73}
             <ffffffff8010dd27>{sysret_signal+28} <ffffffff8010e00f>{ptregscall_common+103}
      
      test          D ffff810011362100     0 14309      1         14305 14312 (NOTLB)
      ffff810053c81cf8 0000000000000082 0000000000000286 0000000000000001
             0000000000000195 ffff810011362340 ffff810011362100 ffff81002e338040
             ffff810001e0ca80 0000000000000001
      Call Trace:<ffffffff801317ed>{try_to_wake_up+893} <ffffffff8044677d>{wait_for_completion+173}
             <ffffffff80131810>{default_wake_function+0} <ffffffff80137435>{exit_mm+149}
             <ffffffff801381af>{do_exit+479} <ffffffff80138d0c>{do_group_exit+252}
             <ffffffff801436db>{get_signal_to_deliver+1451} <ffffffff8010d3ad>{do_signal+157}
             <ffffffff8013deee>{ptrace_check_attach+222} <ffffffff80140850>{specific_send_sig_info+2
      
             <ffffffff8014208a>{force_sig_info+186} <ffffffff804479a0>{do_int3+112}
             <ffffffff8010e308>{retint_signal+61}
      test          D ffff81002e338040     0 14311      1         14716 14305 (NOTLB)
      ffff81005ca8dcf8 0000000000000082 0000000000000286 0000000000000001
             0000000000000120 ffff81002e338280 ffff81002e338040 ffff8100481cb740
             ffff810001e0ca80 0000000000000001
      Call Trace:<ffffffff801317ed>{try_to_wake_up+893} <ffffffff8044677d>{wait_for_completion+173}
             <ffffffff80131810>{default_wake_function+0} <ffffffff80137435>{exit_mm+149}
             <ffffffff801381af>{do_exit+479} <ffffffff80142d0e>{__dequeue_signal+558}
             <ffffffff80138d0c>{do_group_exit+252} <ffffffff801436db>{get_signal_to_deliver+1451}
             <ffffffff8010d3ad>{do_signal+157} <ffffffff8013deee>{ptrace_check_attach+222}
             <ffffffff80140850>{specific_send_sig_info+208} <ffffffff8014208a>{force_sig_info+186}
             <ffffffff804479a0>{do_int3+112} <ffffffff8010e308>{retint_signal+61}
      
      test          D ffff810017ca4180     0 14312      1         14309 13882 (NOTLB)
      ffff81005d15fcb8 0000000000000082 ffff81005d15fc58 ffffffff80130816
             0000000000000897 ffff810017ca43c0 ffff810017ca4180 ffff81003e8118c0
             0000000000000082 ffffffff801317ed
      Call Trace:<ffffffff80130816>{activate_task+150} <ffffffff801317ed>{try_to_wake_up+893}
             <ffffffff8044677d>{wait_for_completion+173} <ffffffff80131810>{default_wake_function+0}
             <ffffffff8018cdc3>{do_coredump+819} <ffffffff80445f52>{thread_return+82}
             <ffffffff801436d4>{get_signal_to_deliver+1444} <ffffffff8010d3ad>{do_signal+157}
             <ffffffff8013deee>{ptrace_check_attach+222} <ffffffff80140850>{specific_send_sig_info+2
      
             <ffffffff804472e5>{_spin_unlock_irqrestore+5} <ffffffff8014208a>{force_sig_info+186}
             <ffffffff804476ff>{do_general_protection+159} <ffffffff8010e308>{retint_signal+61}
      Signed-off-by: NAndrea Arcangeli <andrea@suse.de>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Linus Torvalds <torvalds@osdl.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      30e0fca6
  18. 08 9月, 2005 1 次提交
  19. 01 5月, 2005 2 次提交
  20. 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