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

[Hui Kang]

On Thu, Aug 13, 2015 at 11:11 AM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> 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,
Thanks for dig into the level that explains this. I will submit another
patch with the two fixlets

- Hui


>
> -- Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150813/d0410c35/attachment.html>