Date: Wed, 31 Jul 2019 01:13:13 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: vdso clock_gettime and time64 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
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.