I still do not understand the point of PR_DETACH. Why do you think it isHmm, but that's really interesting, I wonder why do
needed without reparenting? OK, I do not really care ;)
Yes, but that's not to hide from do_wait().Not only. Please look at your own code ;) wait_consider_task() checksAnd. To hide the pr_detached task from do_wait(). you changedNo, its hidden by the check in wait_consider_task().
do_notify_parent() to returnd DEATH_REAP.
do_notify_parent() was changed only to not allow the
second notification to the same parent.
exit_state == EXIT_ZOMBIE before p->pr_detached, and thus do_notify_parent()
haas to return DEATH_REAP so that the caller will set EXIT_DEAD. Otherwise
the old parent could see EXIT_ZOMBIE&& pr_detached task again.
But. What if the child stops after PR_DETACH? It will notify the parentAh, so that should be disallowed too, will fix.
anyway, no?
OK. :)Even if the child reparents to the original parent's sub-thread?task_pid_vnr(p). Hmm, the change in reparent_leader doesn't look right,Why not? Whereever we reparented, I allow reparenting again.
at least in case we reparent to sub-thread.
Everything. ptrace relies on do_wait(). wait_consider_task() doesn'tOK.
work if pr_detached (except for WEXITED of course).
OK, at least the above 2 bugs are trivial to fix... :))I am not that sure the last ones are very buggy.Well, I am not sure.