The reason is that the task could have been reparentedThe attached patch implements the PR_DETACH prctlAt first glance, this version does not reparent the caller to init,
command. It detaches the entire process group from
its parent, allowing the parent to still read the detach
code with normal wait().
Can be used to daemonize process with threads.
but still PR_DETACH checks ->real_parent != /sbin/init for unknown
reason...
IIUC, PR_DETACH simply fools ->real_parent so that it think this childIt can check si_code to see what actually happened.
exits, while the child in fact runs after that but do_wait() can't see it.
Why? I don't understand the point.It was the same also when reparenting was done: the
And. 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.
I guess you did this to ensureNo: the do_dignal_parent() is not called in that case too.
exit_notify() paths will set EXIT_DEAD and thus do_wait() can't see this
child again. This looks very ugly I must admit. And not 100% correct, we
notify the parent twice if ->detaching != 0.
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.
And of course, this breaks ptrace _completely_.Why? What exactly breaks?
Stas, I am sorry, I am tired ;) You are sending more and more versionsI am not that sure the last ones are very buggy.
with the different semantics and they all are buggy.