"Serge E. Hallyn" <serge.hallyn@xxxxxxxxxxxxx> writes: > Quoting Andrew Morton (akpm@xxxxxxxxxxxxxxxxxxxx): >> On Mon, 27 Sep 2010 12:14:10 +0200 >> Daniel Lezcano <daniel.lezcano@xxxxxxx> 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? > > Yes, it is. > We have always been able to compile out the ns cgroup right? In which case this is not a backwards incompatible change so much as the permanent removal of a borked kernel feature. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
