[CRIU] Devices nested cgroup problem

[Cyrill Gorcunov]

On Wed, Aug 31, 2016 at 08:48:27AM -1000, Tycho Andersen wrote:
> Hi Cyrill
> 
> [Sorry for the delay, I'm on vacation through Tuesday of next week]

Have a nice vacation!

> 
> On Tue, Aug 30, 2016 at 07:25:55PM +0300, Cyrill Gorcunov wrote:
> > Hi Tycho! You know, I've been playing with our vz7 containers
> > and found pretty interesting issue. If you create nested
> > cgroups in device controller for container then restore will
> > fail, because you write 'a' first but there are "parent" cgroup
> > present.
> > 
> > Here is an example.
> > vzctl start 100
> > vzctl exec 100 mkdir -p /sys/fs/cgroup/devices/one/two
> > (this creates nested cgroups "one", "two" inside container)
> > vzctl suspend
> > vzctl resume
> > ...
> > The restore log was saved in /vz/private/100/dump/Dump/restore.log
> > Failed to restore the Container
> > ---
> > (00.969979) cg: Restoring cgroup property value [a] to [devices//machine.slice/100/one/devices.deny]
> > (00.969994) Error (criu/cgroup.c:1209): cg: Failed writing a to devices//machine.slice/100/one/devices.deny: Invalid argument
> > (01.007631) Error (criu/cr-restore.c:1021): 157997 killed by signal 9: Killed
> > (01.007746) Error (criu/cr-restore.c:1912): Restoring FAILED.
> > 
> > The above happens because we're writting 'a' into 'deny' in children, which is
> > not allowed in kernel.
> > 
> > Actually I think we should not write 'a' in nested cgroups, only
> > write on toplevel should be done, since the children get propagated
> > from the parent.
> 
> Oh, whoops. I think just making these "special" like we have with some
> of the memory properties should be enough; that way we can still
> support checkpoint and restore of these. The attached patch should fix
> it (it does for the new test, at least). Does that work?
> 

Cool! I did a fast test and container no longer fail restoring, but
I need more detailed review/testing. Gonna do it tonight, tomorrow.
Thanks a huge again!