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

From: Paul Menage
Date: Thu May 08 2008 - 19:22:52 EST


On Thu, May 8, 2008 at 7:54 AM, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:
>
> Paul Menage wrote:
> > On Sat, May 3, 2008 at 2:38 PM, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/