Thanks - that's a useful analysis.
The check in reparent_to_init() was to warn about the situation
where someone had deliberately set the exit signal to some
non-zero value and then the child calls reparent_to_init() - it's
telling you that we're about to stomp on your chosen exit signal.
I hadn't thought about the forget_original_parent() case.
So the fix should be to change the debug code in reparent_to_init()
so it doesn't complain if the exit signal is already SIGCHLD. Or
just kill it off altogether.
--- linux-2.4.14-pre3/kernel/sched.c Tue Oct 23 23:09:48 2001
+++ linux-akpm/kernel/sched.c Sun Oct 28 17:23:26 2001
@@ -1250,11 +1250,6 @@ void reparent_to_init(void)
SET_LINKS(this_task);
/* Set the exit signal to SIGCHLD so we signal init on exit */
- if (this_task->exit_signal != 0) {
- printk(KERN_ERR "task `%s' exit_signal %d in "
- __FUNCTION__ "\n",
- this_task->comm, this_task->exit_signal);
- }
this_task->exit_signal = SIGCHLD;
/* We also take the runqueue_lock while altering task fields
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/