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

[Pavel Emelyanov]

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