On 05/25/2017 11:42 AM, Dmitry Safonov wrote:
> On 05/24/2017 07:45 PM, Dmitry Safonov wrote:
>> On 05/24/2017 07:45 PM, Andrey Ryabinin wrote:
>>>
>>>
>>> On 05/24/2017 07:38 PM, Dmitry Safonov wrote:
>>>> On 05/24/2017 07:34 PM, Andrey Ryabinin wrote:
>>>>>
>>>>>
>>>>> On 05/24/2017 07:29 PM, Dmitry Safonov wrote:
>>>>>> On 05/24/2017 06:21 PM, Andrey Ryabinin wrote:
>>>>>>> We already have infrastructure for virtualized vdso, however we use
>>>>>>> it only to change LINUX_VERSION_NAME in container. Simply store 
>>>>>>> container's
>>>>>>> start time - ve->start_timespec in vdso variable - 
>>>>>>> VDSO64_ve_start_timespec,
>>>>>>> and use it in __vdso_clock_gettime() to calculate container's monotonic 
>>>>>>> time.
>>>>>>>
>>>>>>> Make uts_arch_setup_additional_pages()/uts_prep_vdso_pages_locked() to 
>>>>>>> always
>>>>>>> setup new vdso, since previous policy to setup vdso only if 
>>>>>>> uts_ns->name.release
>>>>>>> wouldn't work for virtualized __vdso_clock_gettime()
>>>>>>>
>>>>>>> https://jira.sw.ru/browse/PSBM-66451
>>>>>>> Signed-off-by: Andrey Ryabinin <[email protected]>
>>>>>>
>>>>>> Well, that's all looks good, but I've two questions:
>>>>>>
>>>>>> 1. Where VDSO64_ve_start_timespec is set? I do not see that part.
>>>>>>
>>>>>
>>>>> in uts_arch_setup_additional_pages() and uts_prep_vdso_pages_locked()
>>>>
>>>> Uhm, yes, but that means that ve_ts_write() is broken for
>>>> running CT.
>>>>
>>>
>>> Do we care? Changing monotonic time on the fly doesn't sound like a 
>>> brilliant idea.
>>
>> Ok, if that's not used by vz tools, then:
>> Reviewed-by: Dmitry Safonov <[email protected]>
> 
> What I suggest - may we add a third patch that changes ve_ts_write()
> to return -EACCESS or something if vdso pages array already exists for
> UTS ns?
> 

Go ahead.
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel

Reply via email to