And let me add another note before I forget... On 03/14, Oleg Nesterov wrote: > > On 03/13, josh@xxxxxxxxxxxxxxxx wrote: > > > > > > A process launching a new process with CLONE_FD is explicitly requesting > > that the process be automatically reaped without any other process > > having to wait on it. The task needs to not become a zombie, because > > otherwise, it'll show up in waitpid(-1, ...) > > This is clear. > > But please note that this task can be traced/debugged by unrelated process, > not its real_parent/creator. Say, the system admin does "strace -p". This > simply breaks the current API. > > Again, again, I didn't read this series yet. But the proper solution (afaics) > should move this "autoreap" check in release_task/__ptrace_detach(). If the > task is traced. Debugger should check ->autoreap and skip another > do_notify_parent(). > > Speaking of autoreap... If ->exit_signal is zero, then the exiting child > doesn't send the notification to its parent, still it doesn't autoreap > itself. To me this looks strange, and in fact it seems to me that this > is only by mistake. I am wondering if we can treat ->exit_signal == 0 > as "autoreap" too. As usual, most probably the answer is "no, because it > is too late to change the historical behaviour". But this is off-topic. It is not clear to me what do_wait() should do with ->autoreap child, even ignoring ptrace. Just suppose that real_parent has a single "autoreap" child. Should wait(NULL) hanf then? If yes, who will wake the parent up? If no, I do not see the necessary changes in wait_cosnider_task(). Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
