[CRIU] [PATCH v5 5/5] mount: Restore binfmt_misc content in case of missing mount

[Kirill Tkhai]

On 23.08.2016 14:50, Pavel Emelyanov wrote:
> On 08/23/2016 02:39 PM, Kirill Tkhai wrote:
>>
>>
>> On 22.08.2016 18:47, Pavel Emelyanov wrote:
>>>>>>>> @@ -3355,6 +3365,13 @@ static int populate_mnt_ns(void)
>>>>>>>>  	if (!pms)
>>>>>>>>  		return -1;
>>>>>>>>  
>>>>>>>> +	if (!opts.has_binfmt_misc && stat_image(CR_FD_BINFMT_MISC, &st, 0) == 0) {
>>>>>>>
>>>>>>> This should be the other way. In cr-restore.c we have an array of so called cinfos -- these
>>>>>>> are images that should be pre-loaded during restore. So it's better to add new-style binfmt
>>>>>>> cinfo and read_mnt_ns_img should check cinfo->flags for COLLECT_HAPPENED (not 100% sure it
>>>>>>> handles empty images correctly, plz, check) and add cr-time mount if it had.
>>>>>>
>>>>>> You had suggested to dump any binfmt_misc content (belonging to a mount point or not)
>>>>>> to the file of the same name. So, the new suggestion doesn't work.
>>>>>
>>>>> Why?
>>>>
>>>> Because in case of binfmt_misc image belongs to a real mount, we should not add a cr-time mount;
>>>> it will be restored when real mount is restored.
>>>>
>>>>
>>>> The second thing I should pointed in previous letter, you have suggested to use opts to check
>>>> if image present: https://patchwork.criu.org/patch/1069/:
>>>>
>>>> "For aufs we have opts.aufs bit. For ... overlayfs (?) we have similar.
>>>> We can add binfmt_misc to opts, or have separate entity to ask "whether fs X was
>>>> mounted" for."
>>>>
>>>> Why now we are moving to another "check cinfo->flags for COLLECT_HAPPENED" mechanism???
>>>
>>> My point was that you don't need to call stat_image() in the place you do
>>> explicitly. Instead, add binfmt cinfo that will try to collect the "new style"
>>> binfmt image and will set the boolean flag about whether or not to add fake
>>> mount.
>>
>> Let's say, we collect new binfmt_misc.img and add them to some binfmt_misc_list.
>> But old type binfmt_misc-xxx.img can't be collected this way. No one of cinfos
>> has numeric postfix.
> 
> Olds are collected the old way.
> 
>> So, have we two restore code? One iterates over binfmt_misc_list, another reads
>> binfmt_misc-xxx.img image?
> 
> Yes. And the latter one goes away eventually as it becomes legacy.

---
Another thing abount cinfos collection.

It happens in root_prepare_shared(), while mounting of filesystems is in prepare_namespace(),
which goes earlier.

Should we refuse add_cr_time_mount() scheme for the restore because of that?