From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14479 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: vdso clock_gettime and time64 Date: Wed, 31 Jul 2019 10:30:26 +0200 Message-ID: <87d0hqsj19.fsf@oldenburg2.str.redhat.com> References: <20190731051313.GA27476@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="231844"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-14495-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 31 10:30:46 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 1hsk0S-000y89-Ux for gllmg-musl@m.gmane.org; Wed, 31 Jul 2019 10:30:45 +0200 Original-Received: (qmail 32238 invoked by uid 550); 31 Jul 2019 08:30:42 -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 32220 invoked from network); 31 Jul 2019 08:30:41 -0000 In-Reply-To: <20190731051313.GA27476@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 31 Jul 2019 01:13:13 -0400") X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 31 Jul 2019 08:30:29 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:14479 Archived-At: * Rich Felker: > One looming thing that folks probably aren't going to like about > switching to 64-bit time_t is losing the vdso clock_gettime on old > kernels. Instead of a function call in userspace, you get *two* > syscalls, the first (time64) one failing, every time you call > clock_gettime. Of course the problem goes away immediately if you have > a time64-capable kernel providing the time64 vdso function. > > Is this a problem, and if so, what can be done about it? Some users notice fairly quickly if the vDSO fast path is gone and file bug reports. (This can happen for various reasons, e.g. buggy kernels detecting CPU cycle counter drift when there is actually none.) I don't know to what extent this matters to legacy architectures. Thanks, Florian