Even mounting knowing cgroups (ie ones which already known to VE and
been mounted by vzctl or any other tool for containter sake) is not
that harmless as it might look like. In particular this introduce
additional performance hit. So because we are using bindmount
strategy to grant cgorups to VE we don't need to mount it from
inside of VE anymore and can simply disable.

Signed-off-by: Cyrill Gorcunov <gorcu...@virtuozzo.com>
CC: Vladimir Davydov <vdavy...@virtuozzo.com>
CC: Konstantin Khorenko <khore...@virtuozzo.com>
CC: Pavel Emelyanov <xe...@virtuozzo.com>
CC: Andrey Vagin <ava...@virtuozzo.com>
---
 kernel/cgroup.c |   18 +++++-------------
 1 file changed, 5 insertions(+), 13 deletions(-)

Index: linux-pcs7.git/kernel/cgroup.c
===================================================================
--- linux-pcs7.git.orig/kernel/cgroup.c
+++ linux-pcs7.git/kernel/cgroup.c
@@ -1572,6 +1572,11 @@ static struct dentry *cgroup_mount(struc
        struct cgroupfs_root *new_root;
        struct inode *inode;
 
+#ifdef CONFIG_VE
+       if (!ve_is_super(get_exec_env()) && !(flags & MS_KERNMOUNT))
+               return ERR_PTR(-EACCES);
+#endif
+
        /* First find the desired set of subsystems */
        if (!(flags & MS_KERNMOUNT)) {
                mutex_lock(&cgroup_mutex);
@@ -1615,19 +1620,6 @@ 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
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Reply via email to