Too late for me, but I don't understand this patch after a quick glance. perhaps I missed something... On 01/23, Tycho Andersen wrote: > > @@ -256,6 +256,17 @@ void release_task(struct task_struct *p) > write_lock_irq(&tasklist_lock); > ptrace_release_task(p); > thread_pid = get_pid(p->thread_pid); > + > + /* > + * If we're not the leader, notify any waiters on our pidfds. Note that > + * we don't want to notify the leader until /everyone/ in the thread > + * group is dead, viz. the condition below. > + * > + * We have to do this here, since __exit_signal() will > + * __unhash_processes(), and break do_notify_pidfd()'s lookup. > + */ > + if (!thread_group_leader(p)) > + do_notify_pidfd(p); This doesn't look consistent. If the task is a group leader do_notify_pidfd() is called by exit_notify() when it becomes a zombie (if no other threads), before it is reaped by its parent (unless autoreap). If it is a sub-thread, it is called by release_task() above. Note that a sub-thread can become a zombie too if it is traced. > __exit_signal(p); and, do_notify_pidfd() is called before __exit_signal() which does __unhash_process() -> detach_pid(PIDTYPE_PID). Doesn't this mean that pidfd_poll() can hang? thread_group_exited() won't return true after do_notify_pidfd() above, not to mention that thread_group_empty() is not possible if !thread_group_leader(). So. When do we want to do do_notify_pidfd() ? Whe the task (leader or not) becomes a zombie (passes exit_notify) or when it is reaped by release_task? Either way pidfd_poll() needs more changes with this patch and it can't use thread_group_exited(). If do_notify_pidfd() is called by release_task() after __exit_signal(), it can just check pid_has_task(PIDTYPE_PID). Oleg.
