Re: [PATCH 6/6] clone4: Introduce new CLONE_FD flag to get task exit notification via fd
From: Oleg Nesterov <hidden>
Date: 2015-03-14 14:32:35
Also in:
linux-fsdevel, lkml
And let me add another note before I forget... On 03/14, Oleg Nesterov wrote:
On 03/13, josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org wrote:quoted
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.