Re: [PATCH 0/3][V2] remove the ns_cgroup

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

On Mon, 27 Sep 2010 12:14:10 +0200
Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> wrote:

> The ns_cgroup is a control group interacting with the namespaces.
> When a new namespace is created, a corresponding cgroup is 
> automatically created too. The cgroup name is the pid of the process
> who did 'unshare' or the child of 'clone'.
> 
> This cgroup is tied with the namespace because it prevents a
> process to escape the control group and use the post_clone callback,
> so the child cgroup inherits the values of the parent cgroup.
> 
> Unfortunately, the more we use this cgroup and the more we are facing
> problems with it:
> 
>  (1) when a process unshares, the cgroup name may conflict with a previous
>  cgroup with the same pid, so unshare or clone return -EEXIST
> 
>  (2) the cgroup creation is out of control because there may have an
>  application creating several namespaces where the system will automatically
>  create several cgroups in his back and let them on the cgroupfs (eg. a vrf
>  based on the network namespace).
> 
>  (3) the mix of (1) and (2) force an administrator to regularly check and
>  clean these cgroups.
> 
> This patchset removes the ns_cgroup by adding a new flag to the cgroup
> and the cgroupfs mount option. It enables the copy of the parent cgroup
> when a child cgroup is created. We can then safely remove the ns_cgroup as
> this flag brings a compatibility. We have now to manually create and add the
> task to a cgroup, which is consistent with the cgroup framework.

So this is a non-backward-compatible userspace-visible change?

What are the implications of this?