Re: [-mm][PATCH 3/4] Add rlimit controller accounting and control

["Paul Menage" <menage@google.com>]

On Thu, May 8, 2008 at 7:54 AM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>
> Paul Menage wrote:
>  > On Sat, May 3, 2008 at 2:38 PM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>  >>  +
>  >>  +int rlimit_cgroup_charge_as(struct mm_struct *mm, unsigned long nr_pages)
>  >>  +{
>  >>  +       int ret;
>  >>  +       struct rlimit_cgroup *rcg;
>  >>  +
>  >>  +       rcu_read_lock();
>  >>  +       rcg = rlimit_cgroup_from_task(rcu_dereference(mm->owner));
>  >>  +       css_get(&rcg->css);
>  >>  +       rcu_read_unlock();
>  >>  +
>  >>  +       ret = res_counter_charge(&rcg->as_res, (nr_pages << PAGE_SHIFT));
>  >>  +       css_put(&rcg->css);
>  >>  +       return ret;
>  >>  +}
>  >
>  > You need to synchronize against mm->owner changing, or
>  > mm->owner->cgroups changing. How about:
>  >
>
>  My mind goes blank at times, so forgive me asking, what happens if we don't use
>  task_lock(). mm->owner cannot be freed, even if it changes, we get the callback
>  in mm_owner_changed(). The locations from where we call _charge and _uncharge,
>  we know that the mm is not going to change either.

I guess I'm concerned about a race like:

A and B are threads in cgroup G, and C is a different process
A->mm->owner == B

A: enter rlimit_cgroup_charge_as()
A: charge new page to G
C: enter attach_task(newG, B)
C: update B->cgroup to point to newG
C: call memrlimit->attach(G, newG, B)
C: charge mm->total_vm to newG
C: uncharge mm->total_vm from G
A: add new page to mm->total_vm

Maybe this can be solved very simply by just taking mm->mmap_sem in
rlimit_cgroup_move_task() and rlimit_cgroup_mm_owner_changed() ? Since
mmap_sem is (I hope) held across all operations that change
mm->total_vm

>
>>  Consider the following scenario
>
>  We try to move task "t1" from cgroup "A" to cgroup "B".
>  Doing so, causes "B" to go over it's limit, what do we do?
>  Ideally, we would like to be able to go back to cgroups and say, please fail
>  attach, since that causes "B" to go over it's specified limit.
>

OK, that sounds reasonable - that's what the can_attach() callback is for.

Paul