On 06/02, Paul Menage wrote: > > On Wed, Jun 2, 2010 at 7:06 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > > > I am not sure. It doesn't hurt when we try to move a thread. But if > > we want to move the whole thread group, we should proceed even if the > > group leader has already exited and thus has PF_EXITING bit set. > > Hmm, maybe. I could see this being argued both ways. Can the process > hang around indefinitely with the leader as a zombie and the other > threads still running? Yes sure. The main thread can exit via sys_exit(), this doesn't affect the thread group. Of course, I am not saying this is common practice, perhaps no "important" app does this. > It wouldn't be that hard to make it possible to avoid relying on > PF_EXITING as the check - instead we'd have an exiting_css_set object > that have the same pointer set as init_css_set, but would be > distinguishable from it as a task->cgroups pointer by virtue of being > a different object. Then cgroup_exit() can reassign tasks to point to > exiting_css_set rather than init_css_set, and the various checks that > are currently made for (task->flags & PF_EXITING) could check for > (task->cgroups == exiting_css_set) instead. This would allow task > movement further into the exit process. It is too late for me to even try to understand the above ;) But I still can't understand why we can't just remove it. Both cgroup_attach_task() and cgroup_attach_proc() should handle the possible races correctly anyway. Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
