From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14477 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: vdso clock_gettime and time64 Date: Wed, 31 Jul 2019 01:13:13 -0400 Message-ID: <20190731051313.GA27476@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="231659"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14493-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 31 07:13:31 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 1hsgvb-000yBi-7w for gllmg-musl@m.gmane.org; Wed, 31 Jul 2019 07:13:31 +0200 Original-Received: (qmail 13712 invoked by uid 550); 31 Jul 2019 05:13:28 -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 13680 invoked from network); 31 Jul 2019 05:13:27 -0000 Content-Disposition: inline Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14477 Archived-At: 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? Obviously it's possible to grab the legacy time32 vdso symbol and wrap it with a function to translate. Aside from being more code and complexity, the problem with this is that it precludes the ability to checkpoint/resume long-lived processes from an old kernel to a new one with time64, which might become a real need in some environments where people realize they've screwed up at the last minute as Y2038 is approaching. What might make sense is checking that the tv_sec obtained from the legacy time32 vdso function is non-negative, and disabling it permanently if the check fails, reverting to syscalls. This would be safe for any process that makes at least one call to clock_gettime before ~2106 after migration. Alternatively we could figure the burden is on someone performing such checkpoint/resume to figure out how to patch process images to disable the no-longer-usable vdso, and that musl has no role in making it work. (Note that this is something of a position advocating for tools poking at internals, which I don't like...) The cleanest course of action is of course just not using the 32-bit vdso at all, and accepting that clock_gettime will be slower until you get a Y2038-safe kernel. Thoughts? Rich