[CRIU] --ext-mount-map auto likes MS_BIND too much

[Tycho Andersen]

On Wed, Apr 15, 2015 at 02:50:47PM +0300, Andrew Vagin wrote:
> On Tue, Apr 14, 2015 at 12:00:54PM -0600, Tycho Andersen wrote:
> > 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()
> >
> 
> +1
> 
> I suggested something like this here:
> http://lists.openvz.org/pipermail/criu/2015-April/019592.html

Sorry, I meant to reply to that thread but forgot. It seems like it
would be nice to have the kernel at least expose the MNT_LOCK_* flags
somehow, and if that's the case, maybe also expose some way for us to
check that mounts are inherited from their parent namespace. I guess
we could check the MNT_LOCK_* flags for unprivileged tasks, but for
privileged ones we would need some other way?

Otherwise, it feels like we've traded the user having to supply a
bunch of --ext-mount-map options for a bunch of --skip-mnt options.

I looked around for a while yesterday and I couldn't figure out how to
implement come_on_this_mount_doesn_t_need_external() without
additional help from the kernel :(

Tycho

> > :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.
> > > 
> > _______________________________________________
> > CRIU mailing list
> > CRIU at openvz.org
> > https://lists.openvz.org/mailman/listinfo/criu