[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 1 Aug 2019 11:16:02 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: vdso clock_gettime and time64
* Szabolcs Nagy <nsz@...t70.net> [2019-07-31 18:47:55 +0200]:
> * Rich Felker <dalias@...c.org> [2019-07-31 11:07:25 -0400]:
> > Thinking about it more, I'm actually concerned about how vdso can
> > possibly work at all with checkpoint/resume functionality. The code in
> > the vdso has to match the running kernel (which will update the data
> > it reads), but the suspended task could be in the middle of vdso code,
> > and even if not it's already bound the function entry point addresses
> > and knowledge of which ones exist. We probably need the answer to this
> > to know if there's even a meaningful problem to solve here. (And if
> > this somehow isn't a question with a known answer already, someone's
> > going to have a really bad day...)
>
> even if the vdso is the same, criu has issues because
> the time is different at restore, so there is a time
> namespace proposal to address this
>
> https://marc.info/?l=linux-api&m=156443756221829&w=2
> https://www.linuxplumbersconf.org/event/2/contributions/202/attachments/25/28/LPC2018__Time_Namespace_4.pdf
>
> if the kernel version is different then i doubt criu
> can be reliable anyway.
hm vdso is mentioned in
https://criu.org/What_can_change_after_C/R
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
