Messages in this thread | | | Date | Mon, 24 Mar 2008 09:34:39 -0700 | From | "Paul Menage" <> | Subject | Re: [RFC][-mm] Memory controller add mm->owner |
| |
On Mon, Mar 24, 2008 at 9:21 AM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > > Also, if mm->owner exits but mm is still alive (unlikely, but could > > happen with weird custom threading libraries?) then we need to > > reassign mm->owner to one of the other users of the mm (by looking > > first in the thread group, then among the parents/siblings/children, > > and then among all processes as a last resort?) > > > > The comment in __exit_signal states that > > "The group leader stays around as a zombie as long > as there are other threads. When it gets reaped, > the exit.c code will add its counts into these totals."
Ah, that's useful to know.
> > Given that the thread group leader stays around, do we need to reassign > mm->owner? Do you do anything special in cgroups like cleanup the > task_struct->css->subsys_state on exit? >
OK, so we don't need to handle this for NPTL apps - but for anything still using LinuxThreads or manually constructed clone() calls that use CLONE_VM without CLONE_PID, this could still be an issue. (Also I guess there's the case of someone holding a reference to the mm via a /proc file?)
> > >> - rcu_read_lock(); > >> - mem = rcu_dereference(mm->mem_cgroup); > >> + mem = mem_cgroup_from_task(mm->owner); > > > > I think we still need the rcu_read_lock(), since mm->owner can move > > cgroups any time. > > > > OK, so cgroup task movement is protected by RCU, right? I'll check for all > mm->owner uses. >
Yes - cgroup_attach() uses synchronize_rcu() before release the cgroup mutex. So although you can't guarantee that the cgroup set won't change if you're just using RCU, you can't guarantee that you're addressing a still-valid non-destroyed (and of course non-freed) cgroup set.
Paul
| |