[Devel] [PATCH vz8 v2] binfmt_misc: fix mount after umount in CT

Nikita Yushchenko nikita.yushchenko at virtuozzo.com
Wed Oct 20 08:51:40 MSK 2021


20.10.2021 07:44, Vasily Averin wrote:
> On 19.10.2021 22:26, Nikita Yushchenko wrote:
>>>> +#ifdef CONFIG_VE
>>>> +        ve->binfmt_misc = bm_data;
>>>> +        /* this will be cleared by ve_destroy() */
>>>> +#endif
>>>> +    }
>>>>
>>>>         err = simple_fill_super(sb, BINFMTFS_MAGIC, bm_files);
>>>> -    if (err) {
>>>> -        kfree(bm_data);
>>>> +    if (err)
>>>>             return err;
>>>> -    }
>>>
>>> I do not have vz8 three, so I'm sorry for dump question:
>>> if we failed here, who will free bm_data and clean up ve->binfmt_misc?
>>
>> Just read a comment several lines above ;)
>>
>> ve->bm_data is global, not per-mount. It is created at first mount (successful or not) and cleared at VE destroy time.
> 
> :) I missed this.
> 
> However anyway, this may be tricky. In past, we had no guarantee that ve will be freed and destroyed after end of CT stop, because some long-lived objects could keep the reference to ve. This may happen during refcont leaks too.
> 
> So CT may be re-started again with old ve.
> I afraid in this case old ve->binfmt_misc can be not released and can be reused.
> Could you please check -- is this acceptable for binfmt_misc?

Idea to reuse VE for a new container surprises me.
VE stores a lot of per-CT state.

Anyway, making binfmt_misc per-VE and freeing it in ve_destroy() is not introduced by this patch. This 
patch only makes things more consistent, in particular ensures that mount-after-unmount does not fail.


More information about the Devel mailing list