[CRIU] [PATCH 1/2] cgroups: Add ability to reuse precreated controllers and cgroups

[Cyrill Gorcunov]

On Fri, May 22, 2015 at 03:10:01PM +0300, Pavel Emelyanov wrote:
> On 05/22/2015 03:03 PM, Cyrill Gorcunov wrote:
> > On Fri, May 22, 2015 at 02:53:22PM +0300, Pavel Emelyanov wrote:
> >> On 05/21/2015 10:33 PM, Cyrill Gorcunov wrote:
> >>> When been playing wich checkpoint/restore of container I found
> >>> that we can't reuse existing controller if they were pre-created.
> >>> For example currently in PCS7 we're bindmount cgroups which belong
> >>> to a container in a form of
> >>>
> >>>  /sys/fs/cgroup/<controller>/<container> ==> /sys/fs/cgroup/<controller>
> >>>
> >>> so that CRIU dumps such configuration fine but on restore
> >>> it recreates controllers from the scratch which we would
> >>> like to bindmount them and ask CRIU to restore subcgroups
> >>> and their parameters.
> >>>
> >>> So I extended --manage-cgroups option to take <mode> arguments
> >>> which might be
> >>>
> >>>  - strict: default mode -- no change in current behaviour,
> >>>    we restore everything from the scratch failing with error
> >>>    if some toplevel controller or cgroup already exist
> >>
> >> What do you mean by "default"? The mode when --mange-cgroups is
> >> specified, but "mode" (argument) is not?
> > 
> > Yes. To keep backward compatibility.
> 
> The current behavior is _not_ to fail if some cgroup exists, but to
> take it as is w/o modifying its parameters and populate with tasks.

No. current behaviour is to fail if some cgroup exist, so that's why
I assigned "strict" as default mode, ie when --manage-cgroup passed
it's the same as --manage-cgroup=strict

> >> I see that modes can be OR-ed. What do the combinations mean?
> > 
> > At the momen it doesn't do anything useful, because there are
> > only plain tests when we're handling cgroups (ie most relaxed
> > mode is tested first). But I think we might extend the semantics
> > in future that's where OR came from.
> 
> OK, but maybe we should override modes with newer ones instead of
> silently "not doing anything useful"?

You mean in option's parsing routine? If so, sure we can.