From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14482 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 19:11:40 +0200 Message-ID: <87o91am8mr.fsf@oldenburg2.str.redhat.com> 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 Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="78789"; 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-14498-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 31 19:13:13 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 1hssA4-000KOc-V1 for gllmg-musl@m.gmane.org; Wed, 31 Jul 2019 19:13:13 +0200 Original-Received: (qmail 26347 invoked by uid 550); 31 Jul 2019 17:11:56 -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 26252 invoked from network); 31 Jul 2019 17:11:55 -0000 In-Reply-To: <20190731150725.GB9017@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 31 Jul 2019 11:07:25 -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.39]); Wed, 31 Jul 2019 17:11:43 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:14482 Archived-At: * Rich Felker: > On Wed, Jul 31, 2019 at 10:30:26AM +0200, Florian Weimer wrote: >> * 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. > > These are good points. A lot of these archs actually don't even have > vdso clock_gettime (only mips, arm, and i386 seem to). > > I wonder if it would make sense to support use of 32-bit vdso for now, > possibly with logic to drop it if it ever returns a negative tv_sec, > and consider removing it after the last kernel without time64 is > EOL'd, so that it's gone well before 2038. In glibc, we perform vDSO lookup early. I will push for a solution that does a probing system call during startup if it cannot find the *_time64 vDSO entry, to determine if it should use the real *_time64 system call or the 32-bit system call (or vDSO). That should help to keep the complexity at bay, at the cost of increased startup time, but which will reduce with future completion of the interfaces. I do not think resuming a process on a kernel with a different system call set is supportable. Thanks, Florian