Re: [PATCH v4 2/6] memcg: split part of memcg creation to css_online

[Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>]

On Tue, 22 Jan 2013 17:47:37 +0400
Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:

> This patch is a preparatory work for later locking rework to get rid of
> big cgroup lock from memory controller code.

Is this complete?  From my reading, the patch is also a bugfix.  It
prevents stale tunable values from getting installed into new children?

> The memory controller uses some tunables to adjust its operation. Those
> tunables are inherited from parent to children upon children
> intialization. For most of them, the value cannot be changed after the
> parent has a new children.
> 
> cgroup core splits initialization in two phases: css_alloc and css_online.
> After css_alloc, the memory allocation and basic initialization are
> done. But the new group is not yet visible anywhere, not even for cgroup
> core code. It is only somewhere between css_alloc and css_online that it
> is inserted into the internal children lists. Copying tunable values in
> css_alloc will lead to inconsistent values: the children will copy the
> old parent values, that can change between the copy and the moment in
> which the groups is linked to any data structure that can indicate the
> presence of children.

That describes the problem, but not the fix.  Don't we need something
like "therefore move the propagation of tunables into the css_online
handler".

What remains unclear is how we prevent races during the operation of
the css_online handler.  Suppose mem_cgroup_css_online() is
mid-execution and userspace comes in and starts modifying the parent's
tunables?