[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