[CRIU] [PATCH] Allow dumping of pstore, securityfs, fusectl, debugfs

[Serge Hallyn]

Quoting Pavel Emelyanov (xemul at parallels.com):
> On 06/10/2014 06:41 PM, Serge Hallyn wrote:
> > Quoting Pavel Emelyanov (xemul at parallels.com):
> >> On 06/09/2014 09:32 PM, Tycho Andersen wrote:
> >>> Hi Pavel,
> >>>
> >>> On Mon, Jun 09, 2014 at 08:25:39PM +0400, Pavel Emelyanov wrote:
> >>>> On 06/09/2014 08:04 PM, Tycho Andersen wrote:
> >>>>>
> >>>>> +
> >>>>>  static struct fstype fstypes[] = {
> >>>>>  	{
> >>>>>  		.name = "unsupported",
> >>>>> @@ -738,6 +750,22 @@ static struct fstype fstypes[] = {
> >>>>>  	}, {
> >>>>>  		.name = "btrfs",
> >>>>>  		.code = FSTYPE__UNSUPPORTED,
> >>>>> +	}, {
> >>>>> +		.name = "pstore",
> >>>>> +		.dump = pstore_dump,
> >>>>> +		.code = FSTYPE__PSTORE,
> >>>>
> >>>> I haven't worked with pstore, thus the question -- what if we
> >>>> just umount it on one box and mount on another without doing
> >>>> anything about preserving its contents. Will it affect the container?
> >>>
> >>> pstore is "platform persistent storage", so it should not be migrated
> >>> with the container. The only real reason it is here is because
> >>> ubuntu's mountall wants to mount it. The default apparmor rules
> >>> disallow changes by containers to all of these filesystems.
> >>>
> >>> After some discussion with Serge Hallyn, it sounds like at some point
> >>> in the future we might allow writes to /sys/fs/fuse, but for now we
> >>> don't. All this patch really does for us is allow dump to complete
> >>> successfully so we can start working on restore.
> >>
> >> OK, this is reasonable. I will apply the patch once one more comment
> >> (below) is resolved. And I'd also appreciate one more patch on top of 
> >> it that actually checks that the FS we dump is really empty (like it's
> >> done for binfmt_misc in criu code).
> > 
> > It's unfortunate because it means the container checkpoint may fail
> > due to completely unrelated actions on the host, but I do see the
> > reason for it.  
> 
> Yes, you're right. These FS-s are still global.
> 
> > It'd be nice if we could only reject checkpoint if
> > a task in the container had an open fd for a file in one of those
> > filesystems.  That wouldn't catch a case where a task opened the
> > file on occasion and got confused by the file going away at
> > restart, but then the host could simply umount the filesystems (and
> > have that propagate into the container) having the same effect.
> > 
> > Thoughts?
> 
> Yup, this makes sense to me. We can do this checking in the
> dump_one_reg_file -- it searches for the mountpoint it belongs
> to anyway, out of that mountpoint we can get the fstype and
> reject the dump if it's the "bad one".

Awesome, thanks.

-serge