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

[Tycho Andersen]

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)

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