[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
