[CRIU] implementing some kind of --leave-frozen option for c/r in CRIU

[Batalov Eugene]

About mnt namespaces. We call prepare_mnt_ns(). This does a bunch of things
and gets to mount.c:

> 3185     ret = mnt_tree_for_each(pms, do_mount_one);

I haven't implemented criu restore ever but one of the ways to implement
mount namespace restore is to create its whole fs tree (with root mount
point and all the submounts) then create new mnt ns, then enter it. then
pivot root in it, then exit from ns. It looks like CRIU restore and
particularly prepare_mnt_ns()  does the same thing.

About networking. Look inside network_unlock_internal(). Our folk has
missed its call and we'll add it to into our patch.
This network_unlock_internal() calls switch_ns and restore_ns back with
iptables manipulation between them.

2016-05-16 20:55 GMT+03:00 Tycho Andersen <tycho.andersen at canonical.com>:

> On Mon, May 16, 2016 at 08:47:26PM +0300, Batalov Eugene wrote:
> > Conceptually we're able to get the same state in criu gc as criu restore
> > gets.
> >
> > I am agree about namespaces and network unlock. Our folk has missed this.
> >
> > About link remaps and namespaces. This thing from patch looks like it
> > should working:
> >
> > > + if (rfe->remap_type == REMAP_TYPE__LINKED) {
> > >  + if (open_remap_linked(rfi, rfe))
> > >  + {
> > >  + pr_err("open_remap_linked failed");
> > >  + return -1;
> > >  + }
> > >  +
> > >  + int mntns_root = mntns_get_root_by_mnt_id(rfi->remap->rmnt_id);
>
> Perhaps I'm missing something, but why is this mntns the same one as
> the task whose mount ns we're trying to clean?
>
> I can see that it might work because you pivot_root() into the same
> --root as the dump/restore is in, but if the container's root isn't
> mounted on the host won't that fail?
>
> Tycho
>



-- 
Best regards,
Eugene Batalov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160516/ddf0ad35/attachment.html>