Messages in this thread | | | Date | Wed, 2 Jun 2010 12:53:33 -0700 | Subject | Re: [RFC] [PATCH 2/2] cgroups: make procs file writable | From | Paul Menage <> |
| |
On Wed, Jun 2, 2010 at 7:06 AM, Oleg Nesterov <oleg@redhat.com> 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
| |