[CRIU] [PATCH] restore: copy special cpuset props recursively

Pavel Emelyanov xemul at parallels.com
Thu Oct 2 03:57:52 PDT 2014


On 09/30/2014 11:50 PM, Tycho Andersen wrote:
> The symptom of this bug was that users restoring tasks to a nested cgroup where
> the top level group was created by criu (and not previously configured) e.g.
> cpuset:/lxc/u1 would get an ENOSPC. criu would try to copy the special
> properties into /lxc/u1 directly and (silently) fail, and then tried to copy
> the task into the cg and fail with ENOSPC:
> 
> ENOSPC Attempted  to  write(2)  an empty cpuset.cpus or cpuset.mems setting to
>        a cpuset that has tasks attached.
> 
> Fixing the silent failure to a loud failure, it gave EACCES:
> 
> EACCES Attempted to add, using write(2), a CPU or memory node to a cpuset, when
>        that CPU or memory node was not already in its parent.
> 
> So, we need to copy the the special props down the entire tree. Additionally,
> we shouldn't copy props directly from the top, since some intermediate point in
> the tree could add restrictions. We first walk back up the tree to find the
> first point where the props are empty, and then copy that parent's props all
> the way down.
> 
> Signed-off-by: Tycho Andersen <tycho.andersen at canonical.com>

Applied.
Can we have some test for this, btw?



More information about the CRIU mailing list