[lkml]   [2002]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] ptrace-fix-2.5.33-A1

On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:

> Right - let me rephrase. Tasks which are either:
> - untraced, normal
> - traced, but traced _by their parent_
> are on the sibling/children list.

hm, why the distinction along whether the debugger == real parent? What
wrong can happen if we always move traced tasks to the ptrace list? The
task will be both in the ptrace list and in the parent's child list, and
everything should work as expected. This looks a more symmetric and
simpler thing to me.

> > this splitup of the lists makes it possible for the debugger to do a wait4
> > that will get events from the debugged task, and for the debugged task to
> > also be available to the real parent.
> Great. I'm not exactly sure on how this works right now: sys_wait4 only
> iterates over ->children, with the exception of the special code in
> TASK_ZOMBIE. I'm not quite sure when events from a traced process get
> to the normal parent of that process, or when they're supposed to.

i'm not sure about this either. What happens if an (untraced) parent has
traced and untraced children, and does a wait4. Would it confuse the
debugger if the parent could get one of the traced tasks as a result in
wait4? And how does the debugger solve this problem?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.102 / U:0.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site