[CRIU] --ext-mount-map auto likes MS_BIND too much
Tycho Andersen
tycho.andersen at canonical.com
Tue Apr 14 11:00:54 PDT 2015
On Tue, Apr 14, 2015 at 07:45:54PM +0200, Oleg Nesterov wrote:
> Hi Tycho,
>
> Before anything else, let me remind that I do not really understand
> this code.
>
> Not only I am very new to criu, I know almost nothing about this
> mount black magic. I still have no idea what this slave/shared/etc
> actually means, and I am thinking in horror that sooner or later
> I will need to read the docs ;)
>
> That said.
>
> On 04/14, Tycho Andersen wrote:
> >
> > > Perhaps resolve_external_mounts() should skip the fsroot_mounted() mount
> > > points at least? Although afaics this is not enough too.
> >
> > I think we can't do an fsroot_mounted() check as we discussed here:
> >
> > http://lists.openvz.org/pipermail/criu/2015-April/019744.html
>
> Thanks, will read tomorrow. But yes, yes, I understand that
> fsroot_mounted() is not an option.
>
> > but yes, something does look wrong :). In this case, the mounts are
> > actually the same mounts, just in different namespaces. Perhaps
> > mounts_equal()
>
> As you already pointed out, this can't work. But let's ignore this.
>
> Afaics, we obviously need the
>
> bool come_on_this_mount_doesn_t_need_external()
:D
> helper called by resolve_external_mounts(). But this is not enough, the
> problem is worse (I think).
>
> What should we do with other ->external checks? Just for example, don't
> we need to chanhge collect_shared()
>
> - if (need_master && m->parent && !m->external)
> + if (need_master && m->parent && !m->external &&
> !come_on_this_mount_doesn_t_need_external(m))
If we have that above, I think it just won't be resolved so the
external bit should be false here, so I think at this point we should
still print the error.
> ?
>
> And can_mount_now() looks suspicious too....
I think (?) this is only a problem if we support internal sharing of
external mounts, which I gave up on because I didn't want to figure
out how to fix it right now :).
Tycho
> Oleg.
>
More information about the CRIU
mailing list