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

[Pavel Emelyanov]

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.

-- Pavel