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

Serge Hallyn serge.hallyn at ubuntu.com
Tue Jun 10 07:41:18 PDT 2014


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.  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?

-serge


More information about the CRIU mailing list