[CRIU] Sync TODO-s for mount.c work

[Oleg Nesterov]

On 04/23, Pavel Emelyanov wrote:
>
> On 04/22/2015 08:48 PM, Oleg Nesterov wrote:
>
> >> We
> >> could have some other option that knows how to do this, though (or
> >> figure out how to detect the "same" mounts somehow and remove this
> >> restriction).
> >
> > To me, "remove this restriction" makes much more sense. In fact, this
> > restriction looks like a bug to me.
> >
> > Once again, in this particular case "auto" will wrongly treat all
> > mounts (except /) as a bind mount. This just means that you can never
> > use this option if the process inherits some mntpoint from parent ns.
>
> Now I'm getting confused, sorry :(
>
> If we unshare the mount namespace and have all the mountpoints "cloned",
> why can't we use the --ext-mount-map auto option? All these cloned mounts
> will either have roots accessible from new tree or not. In the former case
> mountpoint will be (should be) treated as internal and "just dumped", and
> in the latter case criu will scan for criu mntns for the "matching" mount
> and will (should) find one.

I'll write another email in reply to Tycho, let me only explain how/where
the current code fails. This is simple, the solution is not.

> So what's the problem then? :)

Note that (if opts.autodetect_ext_mounts) resolve_external_mounts() calls
find_best_external_match() unconditionally, and it always finds the match
from the parent ns. Even if we used mounts_equal(bind => false), this will
still wrongly return a false positive.

And this means that every mount (except "/") will be wrongly autodetected
as "autodetected external mount ". "dump" succeds, but "restore" will simply
do mount(MS_BIND).

And no, it is not that we can simply filter out these cloned mountpoints
in resolve_external_mounts(). This is more complicated.

Oleg.