Re: [RFC v3 04/23] sysdeps/clock_gettime: Use clock_gettime64 if avaliable

[Florian Weimer <fweimer at redhat dot com>]

* Arnd Bergmann:

> 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.

vDSO parsing happens ahead of time, during initialization, so the rules
are slightly different than with numbered syscall fallback.  System call
wrappers with both INLINE_VSYSCALL and fallback are really suspicious
and probably not a good idea in general.

The real question is whether vDSO and its constituent functions are
optional from a userspace ABI perspective.  If they are mandatory, we
can go straight to the 32-bit vDSO, and, possibly after that, the 32-bit
system call.  Instead of the vDSO implementation, we would install our
own emulation in the function pointer.  If the 64-bit vDSO is optional,
we would likely have to probe the 64-bit system call once, to keep
things sane and simple, and switch between the system call wrapper and
the fallback implementation (same as for the mandatory vDSO case).

Thanks,
Florian