On Wed, Jun 2, 2010 at 7:06 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > Yes sure, I understand this part. cgroup_attach_task() correctly checks > PF_EXITING under task_lock(), this protects from the case when this > task has already passed cgroup_exit() which takes this lock too. Right. > > But. This exactly means that the PF_EXITING check in attach_task_by_pid() > is not necessary from the correctness pov (while probably can be considered > as optimization), right? For the value of correctness that was relevant when writing that code originally, I think it's fine. But ... > 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? 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. Paul _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers