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

[Pavel Emelyanov]

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 :)

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

-- Pavel