[CRIU] Sync TODO-s for mount.c work
Oleg Nesterov
oleg at redhat.com
Sat Apr 25 04:50:35 PDT 2015
On 04/24, Tycho Andersen wrote:
>
> On Fri, Apr 24, 2015 at 10:43:06PM +0300, Pavel Emelyanov wrote:
> > On 04/24/2015 09:29 PM, Oleg Nesterov wrote:
> > >
> > > On 04/23, Pavel Emelyanov wrote:
> > >>
> > >> Ah, sure. It should be NOT before master_is_external, like this
> > >>
> > >> (fsroot_mounted(m) || root_is_visible(m)) && !master_is_external()
> > >>
> > >> Provided master_is_external() is false for private mounts, this should
> > >> handle Oleg's case with mount --make-rprivate,
> > > ^^^^^^^^^^^^^
> > > --make-rslave
> > >
> > > How???
> > >
> > > I mean, once again, that we need more changes than correct implementaion
> > > of is_not_external().
> > >
> > > In case of my "--make-rslave" example everything will be master_is_external,
> > > and
> > >
> > >> all mountpoints will be bind-mounted from host with MS_SLAVE flag.
> > >
> > > this won't restore the mountpoint correctly?
> >
> > Why not? Will, but in sub-optimal manner -- instead of just cloning the mounts
> > tree criu will umount all the cloned mountpoints, then all the host mountpoints
> > will be duplicatied (when you bind-mount a point it gets effectively duplicated
> > but with probably different mountpoint) and then moved to slave mode.
>
> I thought (?) this is how it would work now, but Oleg's original
> testcase gives some error about shmem not found, so something must be
> wrong:
>
> http://lists.openvz.org/pipermail/criu/2015-April/019859.html
>
> I suppose this has to do with shmem itself being a bind mount, but I'm
> not sure what.
No, this is because /dev/ is not devtmpfs after "restore" does MS_BIND.
It is an empty dir, there is obviously no /dev/shm which we could mount.
IOW, the problems is not that we can't mount /dev/shm (although we can't
by the same reason), the problem is that /dev/ was not remounted correctly.
"restore" does clean_mnt_ns() and umounts everything (except "/"), then
it does mount("/dev", "/dev", MS_BIND) and wrongly assumes this is all
we need.
Oleg.
More information about the CRIU
mailing list