[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190731150725.GB9017@brightrain.aerifal.cx>
Date: Wed, 31 Jul 2019 11:07:25 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: vdso clock_gettime and time64
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.
Thinking about it more, I'm actually concerned about how vdso can
possibly work at all with checkpoint/resume functionality. The code in
the vdso has to match the running kernel (which will update the data
it reads), but the suspended task could be in the middle of vdso code,
and even if not it's already bound the function entry point addresses
and knowledge of which ones exist. We probably need the answer to this
to know if there's even a meaningful problem to solve here. (And if
this somehow isn't a question with a known answer already, someone's
going to have a really bad day...)
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.
