restore: copy special cpuset props recursively
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@canonical.com>
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
Showing
Please
register
or
sign in
to comment