[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