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

[Tycho Andersen]

Hi Pavel,

On Thu, Oct 02, 2014 at 02:57:52PM +0400, Pavel Emelyanov wrote:
> 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?

Yes, I can write a test. To really test this, we need to remove the
tree in between dump and restore. Is it enough to put the code in
between these calls, or is there some other hook for doing work in
between dump and restore?

test_daemon();
// code to remove the sample tree
test_waitsig();

Tycho