[CRIU] [PATCH] Skip restoring the cgroup root directories when using full mode

[Pavel Emelyanov]

On 08/13/2015 05:08 PM, Hui Kang wrote:
> Hi, Cyrill
> To provide more information about this patch.
> 
> From the cgroup.c, I see that if the restoring stratgy is full, it will always restore all the cgroup properties, which includes /sys/fs/cgroup/cpusets.cpu. As that file is not write-able by criu (i.e., echo "1024" > /sys/fs/cgroup/cpusets.cpu fails), it will cause problem.
> 
> In contrast, when restoring with "soft" mode, the e->n_properties is zero so that restore_cgroup_prop() is not called.
> 
> - Hui
> 
> On Wed, Aug 12, 2015 at 6:00 PM, Cyrill Gorcunov <gorcunov at gmail.com <mailto:gorcunov at gmail.com>> wrote:
> 
>     On Wed, Aug 12, 2015 at 05:37:35PM -0400, Hui Kang wrote:
>     >
>     >      Could you please explain how we end up having empty dir_name here?
>     >
>     >    This happens when restoring a process with cgroup using
>     >    --manage-cgroup=full. 
>     >    To reproduce this error
>     >    1. start a process
>     >    2. mkdir /sys/fs/cgroups/cpusets/foo
>     >    3. echo PID > /sys/fs/cgroups/cpusets/foo/tasks
>     >    4. checkpoint the process
>     >    5. rmdir /sys/fs/cgroups/cpusets/foo or copy the checkedpoint images to a
>     >    different host
>     >    5. /root/criu/criu restore --log-file ./restore.log -vvvv -j 
>     >    --manage-cgroup=full
> 
>     Hmm. Thanks for info! Need to think...

I think I've got the point. Cpuset's top cgroups is not writable at all. Look at
the kernel's update_cpumask() from kernel/cpuset.c file:

static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
                          const char *buf)
{
        int retval;

        /* top_cpuset.cpus_allowed tracks cpu_online_mask; it's read-only */
        if (cs == &top_cpuset)
                return -EACCES;


See? Thus patch makes sense to me with two ... fixlets -- this exception should be
applied only to the cpuset controller and to the restore_special_cpuset_props() too.

-- Pavel