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

[Pavel Emelyanov]

On 10/03/2014 02:09 AM, Tycho Andersen wrote:
> 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. 

That would be great, thanks!

> 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

No, this would be racy. I think we can reuse the pre-restore hook
in zdtm.sh

	"${test}.hook" --pre-restore || return 2

> test_waitsig();
> 
> Tycho
>