[CRIU] [PATCH 2/2] restore: remount /proc after clone(CLONE_NEWPID)

[Andrew Vagin]

On Wed, Aug 06, 2014 at 01:34:07PM -0500, Tycho Andersen wrote:
> Hi Andrew,
> 
> On Wed, Aug 06, 2014 at 10:25:10PM +0400, Andrew Vagin wrote:
> > On Wed, Aug 06, 2014 at 01:06:29PM -0500, Tycho Andersen wrote:
> > > We need to remount /proc after the clone because things like getpid() return
> > > the pid in the new namespace, but /proc still has the old namespace's info in
> > > it. This causes problems when e.g. there are some things in criu's private
> > > mount namespace but not in (the original) init's namespace.
> > 
> > Could you show an example of problems?
> 
> Yes, if you:
> 
> 1. unshare(CLONE_NEWNS)
> 2. mount() some directory to pass as --root
> 3. exec(criu)

Could you show how criu fails in this case?

> 
> criu fails with "(mount.c:1958): New root and old root are the same".
> This is because prepare_mnt_ns calls getpid(), which gives 1 in the
> new PID namespace. If you look in /proc/1/mountinfo, it will look in
> the original init's mountinfo instead of the new init's mountinfo with
> the mount provided by the initial process for --root.
> 
> > > 
> > > Signed-off-by: Tycho Andersen <tycho.andersen at canonical.com>
> > > ---
> > >  cr-restore.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/cr-restore.c b/cr-restore.c
> > > index 88c4b95..6d1c6a2 100644
> > > --- a/cr-restore.c
> > > +++ b/cr-restore.c
> > > @@ -987,6 +987,10 @@ static inline int fork_with_pid(struct pstree_item *item)
> > >  		goto err_unlock;
> > >  	}
> > >  
> > > +	if (cr.clone_flags & CLONE_NEWPID && mount(NULL, "/proc", "proc", MS_REMOUNT, NULL) < 0) {
> > 
> > We can't remount proc, if we don't create a new mount namespace. But
> > when we restore a mount namespace, we restore all mounts in it.
> 
> Ah, that is a good point. I guess CLONE_NEWPID implies CLONE_NEWNS,
> maybe?
> 
> Tycho