[PATCH 2/4] reparent_thread: fix the "is it traced" check

[PATCH 2/4] reparent_thread: fix the "is it traced" check

[Oleg Nesterov]

reparent_thread() uses ptrace_reparented() to check whether this thread
is ptraced, in that case we should not notify the new parent.

But ptrace_reparented() is not exactly correct when the reparented thread
is traced by /sbin/init, because forget_original_parent() has already
changed ->real_parent.

Currently, the only problem is the false notification. But with the next
patch the kernel crash in this (yes, pathological) case.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>

--- 6.29-rc3/kernel/exit.c~6_FIX_PTRACE_CHECK	2009-01-29 06:21:51.000000000 +0100
+++ 6.29-rc3/kernel/exit.c	2009-01-29 06:57:09.000000000 +0100
@@ -826,7 +826,7 @@ static void reparent_thread(struct task_
 	/* If we'd notified the old parent about this child's death,
 	 * also notify the new parent.
 	 */
-	if (!ptrace_reparented(p) &&
+	if (!p->ptrace &&
 	    p->exit_state == EXIT_ZOMBIE && thread_group_empty(p))
 		do_notify_parent(p, p->exit_signal);
 

Re: [PATCH 2/4] reparent_thread: fix the "is it traced" check

[Roland McGrath]

> reparent_thread() uses ptrace_reparented() to check whether this thread
> is ptraced, in that case we should not notify the new parent.

I think at some point in the past, ptracedness could sometimes transfer to
the new parent, so this made sense then (before it had that name).

> But ptrace_reparented() is not exactly correct when the reparented thread
> is traced by /sbin/init, because forget_original_parent() has already
> changed ->real_parent.

Heh.  Ok.  I think the !p->ptrace check is fine.

Acked-by: Roland McGrath <roland@redhat.com>


Thanks,
Roland