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?
--
Dmitry
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
