On 06/01, Paul Menage wrote: > > On Mon, May 31, 2010 at 11:04 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > > > And, forgot to mention, I do not understand the PF_EXITING check in > > attach_task_by_pid() (and some others). > > > > At first glance, it buys nothing. PF_EXITING can be set right after > > the check. > > It can, but it's a benign race. Yes, > Moving a non-current thread into a cgroup takes task->alloc_lock and > checks for PF_EXITING before manipulating that thread's cgroup links. > The exit procedure sets PF_EXITING and then (somewhat later, but > guaranteed) moves current to the root cgroups while holding > alloc_lock. 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. 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? And, > so it's fine to refuse to move it to a new cgroup. 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. That was my question. Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
