From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14481 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: vdso clock_gettime and time64 Date: Wed, 31 Jul 2019 18:47:55 +0200 Message-ID: <20190731164754.GA22009@port70.net> References: <20190731051313.GA27476@brightrain.aerifal.cx> <87d0hqsj19.fsf@oldenburg2.str.redhat.com> <20190731150725.GB9017@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="230479"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14497-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 31 18:48:11 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hsrlq-000xpa-18 for gllmg-musl@m.gmane.org; Wed, 31 Jul 2019 18:48:10 +0200 Original-Received: (qmail 3318 invoked by uid 550); 31 Jul 2019 16:48:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3297 invoked from network); 31 Jul 2019 16:48:07 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190731150725.GB9017@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14481 Archived-At: * Rich Felker [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.