When we restore containers via CRIU we're writting cgroup values from images into appropriate entries. In particualer we're moving tasks into beancounter cgroup and such.
For plain start/stop relaxing this restriction to VE cgroup only was enough but it caused problems on restore of complete container: we simply refuse to continue restoring because we can't attach restored task into beancounter cgroup. So for a while, to test c/r cycles (I got another problems here) I disabled this check but we need somehow to reenable it back. The best option would be to somehow figure out that it's CRIU who is writting the values (or maybe play with current::nsproxy::fowner_ve). Anyway, here is a WARN_ON which will nag us to fix the problem. 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 | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-pcs7.git/kernel/cgroup.c =================================================================== --- linux-pcs7.git.orig/kernel/cgroup.c +++ linux-pcs7.git/kernel/cgroup.c @@ -2361,10 +2361,10 @@ static ssize_t cgroup_file_write(struct * userspace from ve0 should *never* bindmount it * inside a container FS. */ - if (!ve_is_super(get_exec_env()) && - !(cgrp->root->subsys_mask & (1UL << ve_subsys_id)) && - (!cgrp->parent || !cgrp->parent->parent)) - return -EACCES; + if (!ve_is_super(get_exec_env())) { + if (!cgrp->parent || !cgrp->parent->parent) + pr_warn_once("FIXME: Write into toplevel cgroup, restore?"); + } #endif if (cgroup_is_removed(cgrp)) _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
