[CRIU] Dealing with other mount types

[Serge Hallyn]

Quoting Tycho Andersen (tycho.andersen at canonical.com):
> Hi all,
> 
> [As a preface, I don't understand all the issues at play here, so any
> input or corrections are very much welcome.]
> 
> Recent changes in Ubuntu and LXC mean that c/r of LXC containers no longer
> works out of the box, so I'd like to fix that. The first step is to fix some of
> the mount handling. When I start a container on Vivid with LXC 1.1, I get a
> mountinfo that looks like:
> 
> 44 45 253:1 /usr/local/var/lib/lxc/u1/rootfs / rw,relatime master:1 - ext4 /dev/disk/by-uuid/6c5a78e0-95fa-49a8-aa91-a8093d295e58 rw,data=ordered
> 78 44 0:36 / /dev rw,relatime - tmpfs none rw,size=100k,mode=755
> 79 44 0:38 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
> 80 81 0:38 /sys/net /proc/sys/net rw,nosuid,nodev,noexec,relatime - proc proc rw
> 81 79 0:38 /sys /proc/sys ro,nosuid,nodev,noexec,relatime - proc proc rw
> 82 79 0:38 /sysrq-trigger /proc/sysrq-trigger ro,nosuid,nodev,noexec,relatime - proc proc rw
> 83 44 0:39 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
> 84 83 0:39 / /sys ro,nosuid,nodev,noexec,relatime - sysfs sysfs rw
> 85 84 0:39 / /sys/devices/virtual/net rw,relatime - sysfs sysfs rw
> 86 85 0:39 /devices/virtual/net /sys/devices/virtual/net rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
> 87 84 0:34 / /sys/fs/fuse/connections rw,relatime master:23 - fusectl fusectl rw
> 88 84 0:7 / /sys/kernel/debug rw,relatime master:25 - debugfs debugfs rw
> 89 84 0:11 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime master:8 - securityfs securityfs rw
> 90 84 0:23 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime master:11 - pstore pstore rw
> 91 84 0:40 / /sys/fs/cgroup rw,relatime - tmpfs cgroup rw,size=12k,mode=755
> 92 91 0:21 /cgmanager /sys/fs/cgroup/cgmanager rw - tmpfs tmpfs rw,mode=755
> 46 78 0:41 / /dev/pts rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=666
> 47 44 0:42 / /run rw,nosuid,noexec,relatime - tmpfs none rw,size=199952k,mode=755
> 48 47 0:43 / /run/lock rw,nosuid,nodev,noexec,relatime - tmpfs none rw,size=5120k
> 49 47 0:44 / /run/shm rw,nosuid,nodev,relatime - tmpfs none rw
> 50 47 0:45 / /run/user rw,nosuid,nodev,noexec,relatime - tmpfs none rw,size=102400k,mode=755
> 
> First, several things (the rootfs, fuse, pstore, etc.) are mounted as slaves.
> My understanding is that this happens because systemd remounts / as MS_SHARED
> instead of MS_PRIVATE, but it means that we need some way of handling slave
> mounts. One thought is to have an argument similar to --ext-mount-map which
> tells criu which peer group a particular mount is a slave to. For e.g. pstore
> above, this would look like:

Thinking about this semantically.  If the container rootfs is MS_SLAVE, that
means that {u,}mount events on the host are propagated into the container.
Why is that done?  It could be because something like host:/home/ubuntu is
bind-mounted into the container, and when host umounts /home/ubuntu it doesn't
want container:/home/ubuntu to pin the source.

In other words, it is a relation between paths on the host and in the container.
So after restart, do we want to demand that these relations continue to exist?

Probably.  I just wanted to make it clear - this is not about proper behavior
inside the checkpointed container, but about relation between host and container,
and the host, between checkpoint and restart, may change, as may its expectations.

> 1. criu ... --slave-mount-map=/sys/fs/pstore:/sys/fs/pstore # source:target

I think that makes sense.  I also think a general option saying "ignore mounts
propagation outside the container" may make sense - disabled by default of course.

> 2. criu walks the mount tree as usual, and when it sees something in
>    --slave-mount-map:
>     1. criu bind mounts /sys/fs/pstore into $root_yard/sys/fs/pstore
>     2. criu sets MS_SLAVE (by calling restore_shared_options())

Note that depending on the new host, it may even have to first set it
MS_SHARED, then do the bind mount, then change to MS_SLAVE.

> Second, for e.g. /proc/sys, the root of the mount is a path that's relative to
> it's parent's mountpoint. I think (?) this just means that mount.c's
> find_fsroot_mount_for() needs to be a little smarter when it resolves things,
> so it should return /'s mountinfo when called for /proc/sys, instead of

Right - it should see that /proc/sys is /sys from mountid 70 which is /proc
in the container.

> complaining about a proper root mount. Is there something else here that I'm
> missing?
> 
> Tycho