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

[Pavel Emelyanov]

On 08/23/2016 06:31 PM, Kirill Tkhai wrote:
> 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(), 

There's also crtools_prepare_shared() call that also uses cinfo-s and happens earlier :)

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