This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v3 04/23] sysdeps/clock_gettime: Use clock_gettime64 if avaliable
On Wed, Jul 17, 2019 at 10:44 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> >> I believe this needs to be updated for correctness (truncation of
> >> tv_sec) if ever ported to architectures where __nanosleep_nocancel takes
> >> a 32-bit time_t argument. I don't know what our plans are regarding to
> >> that.
> >>
> >> If you had
> >>
> >> #define __NR_clock_gettime64 __NR_clock_gettime
> >>
> >> in <sysdep.h>, you wouldn't need this change.
> >
> > Could it be changed to just call internal __clock_gettime64() and
> > __nanosleep_nocancel_time64() functions that will then take care
> > of the architecture specifics like syscall number, vdso and
> > truncation?
>
> It depends on how these functions behave. I think we need to figure out
> if/how we maintain vDSO acceleration for clock_gettime and
> clock_gettime64 first.
Agreed. In the kernel, the generic clock_gettime64() support only just
landed for 5.3, and so far only arm32 and x86-32 have it, while at
least mips32, nds32, ppc32, s390 and sparc32 seem to have a the
old clock_gettime() and gettimeofday() vdso support.
For the internal __clock_gettime64() implementation, we clearly
want to call __vdso_clock_gettime64() whenever that is available,
but there does not seem to be a good fallback path from there
if it is not:
- if we try syscall(__NR_clock_gettime64) next, that is a performance
regression in systems that don't care about 64-bit time_t
- if we try __vdso_clock_gettime() before __NR_clock_gettime64,
that can result in incorrect behavior if user space actually relies
on being able to work past 2038.
Arnd