Previously we allowed to mount existing cgroups inside container but then it cause a suspicion that if container is mounting too many existing cgoroups this might affect the node's performance. So we disabled this ability. Still because restore procedure is running from inside of VE being restored itself we need to allow mount existing cgroups back because CRIU restores cgroups and all their contents on its own. So if won't the CRIU will fail.
That said probably we should provide some steer via sysfs so node admin would be able to limit the summary number of cgroups mounted inside container. Signed-off-by: Cyrill Gorcunov <[email protected]> CC: Vladimir Davydov <[email protected]> CC: Konstantin Khorenko <[email protected]> CC: Pavel Emelyanov <[email protected]> CC: Andrey Vagin <[email protected]> --- kernel/cgroup.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) Index: linux-pcs7.git/kernel/cgroup.c =================================================================== --- linux-pcs7.git.orig/kernel/cgroup.c +++ linux-pcs7.git/kernel/cgroup.c @@ -1585,17 +1585,6 @@ static struct dentry *cgroup_mount(struc if (ret) goto out_err; -#ifdef CONFIG_VE - /* - * Cgroups mounting from inside of VE is not allowed - * until we get some iron prove that we are to. - */ - if (!ve_is_super(get_exec_env())) { - ret = -EACCES; - goto out_err; - } -#endif - /* * Allocate a new cgroup root. We may not need it if we're * reusing an existing hierarchy. @@ -1626,6 +1615,19 @@ static struct dentry *cgroup_mount(struc int i; struct css_set *cg; +#ifdef CONFIG_VE + /* + * We don't allow to mount new roots from inside + * of container (but have to allow mounting existing + * cgroups, because the VE restore procedure is + * implemented from inside of container environment). + */ + if (!ve_is_super(get_exec_env())) { + ret = -EACCES; + goto drop_new_super; + } +#endif + BUG_ON(sb->s_root != NULL); ret = cgroup_get_rootdir(sb); _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
