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

Pavel Emelyanov xemul at parallels.com
Tue Jun 10 08:23:54 PDT 2014


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

Thanks,
Pavel


More information about the CRIU mailing list