Re: [PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define

[Lukasz Majewski <lukma at denx dot de>]

Hi Joseph,

> On Wed, 8 May 2019, Lukasz Majewski wrote:
> 
> > The 64 bit versions of syscalls (like clock_settime64 or
> > clock_gettime64) are available since 5.1 kernel (as you posted
> > already the following patch: "Update syscall-names.list for Linux
> > 5.1" .
> > 
> > I've now only focused on clock_settime(64) to make the discussion
> > more concrete.  
> 
> The following will be relevant for use of clock_gettime64, but is not 
> immediately relevant for clock_settime64:
> 
> clock_gettime64 will complicate things because the present
> clock_gettime code uses the vDSO on some architectures.

Yes, correct. There are vdso's(__vdso_clock_gettime and
__vdso_gettimeofday) for x64, arm, sparc to name a few.

>  Is
> clock_gettime64 available in the vDSO in 5.1 on all architectures
> where clock_gettime is? 

As fair as I can tell clock_gettime64 is not available as vdso in v5.1
Linux kernel. It is only exported to be used as a syscall.

The other issue with current vdso code (as in [1] or [2]) is that the
struct timespec's tv_sec is 'long', which would be 32 bit on 32 bit
systems (like arm).

> If it is, with the same symbol version as
> used for existing vDSO symbols, or a different symbol version?  If
> not in the vDSO, are there any performance implications from using a
> clock_gettime64 syscall in place of a clock_gettime call to the vDSO?
> 

This would need to be checked how severe is the performance regression
when one uses clock_gettime64 instead of dedicated __vdso_clock_gettime
(aliased to clock_gettime()).

It is also up to the Linux kernel community to decide if it is
acceptable to introduce vclock_gettime64.c file, which would provide
vdso for clock_gettime64.

Or maybe just convert [1], [2] to use struct timespec64 instead?

> (I think the code using the vDSO will automatically fall back to a 
> corresponding syscall if the vDSO symbol isn't there, but answers to
> those questions will still be relevant for reviewing any patch for 
> clock_gettime64 and understanding exactly what code paths it will
> use.)

Yes, correct as in [1], [2].

However, I do believe that on the beginning glibc shall support only
the syscall version of clock_gettime64 and make the switch for vdso
only when it is available from the Kernel.

> 


Note:

[1] - arch/x86/entry/vdso/vclock_gettime.c (5.1)
[2] - arch/arm/vdso/vgettimeofday.c

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Attachment: pgp0D35g_4lfW.pgp
Description: OpenPGP digital signature