[CRIU] [PATCH 1/2] mount: handle tracefs more gracefully

Andrew Vagin avagin at virtuozzo.com
Fri May 20 15:29:11 PDT 2016


On Fri, May 20, 2016 at 02:28:08PM +0300, Pavel Emelyanov wrote:
> On 05/18/2016 03:13 AM, Tycho Andersen wrote:
> > Hi guys,
> > 
> > On Tue, May 17, 2016 at 10:37:22AM -0700, Andrew Vagin wrote:
> >> Hi Tycho,
> >>
> >> Honestly, I don't like this hack. I think it will not work in all cases.
> >>
> >> For example, we create a clean mount, if an required path is
> >> overmounted:
> >>
> >>         if (&c->siblings != &mi->bind->children) {
> >>                 /* Get a copy of mi->bind without child mounts */
> >>                 if (mount(mnt_path, mnt_clean_path, NULL, MS_BIND, NULL)) {
> >>                         pr_perror("Unable to bind-mount %s to %s",
> >>                                         mi->bind->mountpoint, mnt_clean_path);
> >>                 }
> >>                 mnt_path = mnt_clean_path;
> >>                 umount_mnt_path = true;
> >>         }
> >>
> >> so if we will create a clean mount for debugfs, we will lost tracefs.
> >>
> >> Do you bind-mount debugfs from host in a container? If it's yes, you probably
> >> use --mnt-ext-map options for it. Maybe we can add recursive external mounts
> >> or something like this.
> > 
> >>From our IRC discussion, avagin suggested,
> > 
> > avagin | --mnt-ext-map xxx:yyy:opts
> > 
> > which is fine with me. For now, we only need a few options:
> > 
> > 'r' == MS_REC
> > 'i' == ignore the mount on dump (i.e. don't even put it in the images)
> > 
> > with a combination of these two options, I think that we can make the
> > tracefs case work without any other changes to CRIU.
> > 
> > One other thing I noticed is that --ext-mount-map splits on `:`, which
> > will be wrong for paths with a `:` in them. Maybe we don't care about
> > that right now, though :)
> > 
> > What do you guys think? It will work, but it will require everyone who
> > mounts debugfs in a container to handle it this same way, as opposed
> > to being in CRIU proper.
> > 
> > Another way would be to drop the FSTYPE__TRACEFS special case from
> > proc_parse.c in the first patch, and add some kind of hook to the
> > struct fstype which says whether or not to record the fs in the dump
> > image (maybe just a different return value from ->parse?). See the
> > attached patch for what that would look like.
> 
> I like the way it's in this patch :) So patch's applied, thanks, hopefully
> Andrey will like it too :)

I like it. Tycho, thank you for the work.

> 
> And a usual grumble -- would you cook a test for this? :)
> 
> -- Pavel
> 


More information about the CRIU mailing list