[1/6] y2038: Use __clock_settime64 in deprecated stime function
diff mbox series

Message ID 20200118072047.23071-2-lukma@denx.de
State New
Headers show
Series
  • y2038: Convert settimeofday to be Y2038 safe
Related show

Commit Message

Lukasz Majewski Jan. 18, 2020, 7:20 a.m. UTC
Now, internally the deprecated stime uses __clock_settime64. This patch is
necessary for having architectures with __WORDSIZE == 32 &&
__TIMESIZE == 32 (like e.g. ARM32) Y2038 safe.

Build tests:
./src/scripts/build-many-glibcs.py glibcs
---
 time/stime.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Adhemerval Zanella Jan. 20, 2020, 4:58 p.m. UTC | #1
On 18/01/2020 04:20, Lukasz Majewski wrote:
> Now, internally the deprecated stime uses __clock_settime64. This patch is
> necessary for having architectures with __WORDSIZE == 32 &&
> __TIMESIZE == 32 (like e.g. ARM32) Y2038 safe.
> 
> Build tests:
> ./src/scripts/build-many-glibcs.py glibcs
> ---
>  time/stime.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/time/stime.c b/time/stime.c
> index 576fa9c0c9..963902126b 100644
> --- a/time/stime.c
> +++ b/time/stime.c
> @@ -27,11 +27,11 @@ int
>  attribute_compat_text_section
>  __stime (const time_t *when)
>  {
> -  struct timespec ts;
> +  struct __timespec64 ts;
>    ts.tv_sec = *when;
>    ts.tv_nsec = 0;
>  
> -  return __clock_settime (CLOCK_REALTIME, &ts);
> +  return __clock_settime64 (CLOCK_REALTIME, &ts);
>  }
>  
>  compat_symbol (libc, __stime, stime, GLIBC_2_0);
> 

For !__ASSUME_TIME64_SYSCALLS builds time_t will continue to be 32 bits
and stime will continue to be non Y2038 safe.  Also, internally
__clock_settime will first try to issue __NR_clock_settime64, so current
code already accomplishes what this patch is aiming to do.
Lukasz Majewski Jan. 20, 2020, 5:58 p.m. UTC | #2
Hi Adhemerval,

> On 18/01/2020 04:20, Lukasz Majewski wrote:
> > Now, internally the deprecated stime uses __clock_settime64. This
> > patch is necessary for having architectures with __WORDSIZE == 32 &&
> > __TIMESIZE == 32 (like e.g. ARM32) Y2038 safe.
> > 
> > Build tests:
> > ./src/scripts/build-many-glibcs.py glibcs
> > ---
> >  time/stime.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/time/stime.c b/time/stime.c
> > index 576fa9c0c9..963902126b 100644
> > --- a/time/stime.c
> > +++ b/time/stime.c
> > @@ -27,11 +27,11 @@ int
> >  attribute_compat_text_section
> >  __stime (const time_t *when)
> >  {
> > -  struct timespec ts;
> > +  struct __timespec64 ts;
> >    ts.tv_sec = *when;
> >    ts.tv_nsec = 0;
> >  
> > -  return __clock_settime (CLOCK_REALTIME, &ts);
> > +  return __clock_settime64 (CLOCK_REALTIME, &ts);
> >  }
> >  
> >  compat_symbol (libc, __stime, stime, GLIBC_2_0);
> >   
> 
> For !__ASSUME_TIME64_SYSCALLS builds time_t will continue to be 32
> bits and stime will continue to be non Y2038 safe.

This patch is a preparatory work for introducing support of
-D_TIME_BITS=64 compilation flag when compiling programs with glibc [1].

Then the __USE_TIME_BITS64 is defined for exported glibc headers.
After this the time_t will become __time64_t on e.g. ARM32 bits
(__WORDSIZE==32 && __TIMESIZE==32).

As pointed out by Joseph [3], without such code we will not be able
atomically introduce _TIME_BITS=64 support.

>  Also, internally
> __clock_settime will first try to issue __NR_clock_settime64, so
> current code already accomplishes what this patch is aiming to do.

There is a use case when we do need to call __clock_settime64 though:

- ARM32 program is compiled with -D_TIME_BITS=64
- The clock_settime (or stime) internally uses __clock_settime() which
  in this case supports only 32 bit time API.

  To have this system Y2038 safe - one needs to call __clock_settime64
  explicitly to support passing arguments via struct __timespec64.

  This is true for all calls of __clock_settime/__clock_gettime
  (functions to be used internally by glibc, as we ought to switch to
  e.g. struct __timespec64).

Links:

[1] -
https://github.com/lmajewski/y2038_glibc/commit/e03c7188c72dd78d7141cf88f24dd2a5fd14c4f1#diff-a5ab6c74681eaf0569ed54f6bf0d7978R386

[2] -
https://github.com/lmajewski/y2038_glibc/commit/e03c7188c72dd78d7141cf88f24dd2a5fd14c4f1#diff-c051022b496f12bd9028edb46b8ec04dR7

[3] - https://sourceware.org/ml/libc-alpha/2020-01/msg00369.html

[4] -
https://github.com/lmajewski/y2038_glibc/blob/glibc_settimeofday_64bit_conversion_v1/sysdeps/unix/sysv/linux/clock_settime.c#L57



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
Adhemerval Zanella Jan. 20, 2020, 6:17 p.m. UTC | #3
On 20/01/2020 14:58, Lukasz Majewski wrote:
> Hi Adhemerval,
> 
>> On 18/01/2020 04:20, Lukasz Majewski wrote:
>>> Now, internally the deprecated stime uses __clock_settime64. This
>>> patch is necessary for having architectures with __WORDSIZE == 32 &&
>>> __TIMESIZE == 32 (like e.g. ARM32) Y2038 safe.
>>>
>>> Build tests:
>>> ./src/scripts/build-many-glibcs.py glibcs
>>> ---
>>>  time/stime.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/time/stime.c b/time/stime.c
>>> index 576fa9c0c9..963902126b 100644
>>> --- a/time/stime.c
>>> +++ b/time/stime.c
>>> @@ -27,11 +27,11 @@ int
>>>  attribute_compat_text_section
>>>  __stime (const time_t *when)
>>>  {
>>> -  struct timespec ts;
>>> +  struct __timespec64 ts;
>>>    ts.tv_sec = *when;
>>>    ts.tv_nsec = 0;
>>>  
>>> -  return __clock_settime (CLOCK_REALTIME, &ts);
>>> +  return __clock_settime64 (CLOCK_REALTIME, &ts);
>>>  }
>>>  
>>>  compat_symbol (libc, __stime, stime, GLIBC_2_0);
>>>   
>>
>> For !__ASSUME_TIME64_SYSCALLS builds time_t will continue to be 32
>> bits and stime will continue to be non Y2038 safe.
> 
> This patch is a preparatory work for introducing support of
> -D_TIME_BITS=64 compilation flag when compiling programs with glibc [1].
> 
> Then the __USE_TIME_BITS64 is defined for exported glibc headers.
> After this the time_t will become __time64_t on e.g. ARM32 bits
> (__WORDSIZE==32 && __TIMESIZE==32).> 
> As pointed out by Joseph [3], without such code we will not be able
> atomically introduce _TIME_BITS=64 support.

The _TIME_BITS=64 is a redirection for programs build against the glibc
provided headers, not for glibc build *itself*. Otherwise we will change
the ABI depending of the minimum supported kernel (which might define
__ASSUME_TIME64_SYSCALLS).

In this compatibility case we need to always assure the internal
time_t is 32 bits to architecture that provided such interface.


> 
>>  Also, internally
>> __clock_settime will first try to issue __NR_clock_settime64, so
>> current code already accomplishes what this patch is aiming to do.
> 
> There is a use case when we do need to call __clock_settime64 though:
> 
> - ARM32 program is compiled with -D_TIME_BITS=64
> - The clock_settime (or stime) internally uses __clock_settime() which
>   in this case supports only 32 bit time API.

Arm programs linked against old glibc will need to continue to call
stime with time_t being 32-bits.  The stime won't be exported for
-D_TIME_BITS=64, neither a stime64 will be implemented.

> 
>   To have this system Y2038 safe - one needs to call __clock_settime64
>   explicitly to support passing arguments via struct __timespec64.
> 
>   This is true for all calls of __clock_settime/__clock_gettime
>   (functions to be used internally by glibc, as we ought to switch to
>   e.g. struct __timespec64).

The idea of deprecate and make stime a compat symbol is exactly to avoid
need to provide a Y2038 version of it. Newer programs that aim to be
Y2038 safe will need to use clock_settime instead.


> 
> Links:
> 
> [1] -
> https://github.com/lmajewski/y2038_glibc/commit/e03c7188c72dd78d7141cf88f24dd2a5fd14c4f1#diff-a5ab6c74681eaf0569ed54f6bf0d7978R386
> 
> [2] -
> https://github.com/lmajewski/y2038_glibc/commit/e03c7188c72dd78d7141cf88f24dd2a5fd14c4f1#diff-c051022b496f12bd9028edb46b8ec04dR7
> 
> [3] - https://sourceware.org/ml/libc-alpha/2020-01/msg00369.html
> 
> [4] -
> https://github.com/lmajewski/y2038_glibc/blob/glibc_settimeofday_64bit_conversion_v1/sysdeps/unix/sysv/linux/clock_settime.c#L57
> 
> 
> 
> 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
>
Lukasz Majewski Jan. 21, 2020, 4:54 p.m. UTC | #4
Hi Adhemerval,

> On 20/01/2020 14:58, Lukasz Majewski wrote:
> > Hi Adhemerval,
> >   
> >> On 18/01/2020 04:20, Lukasz Majewski wrote:  
> >>> Now, internally the deprecated stime uses __clock_settime64. This
> >>> patch is necessary for having architectures with __WORDSIZE == 32
> >>> && __TIMESIZE == 32 (like e.g. ARM32) Y2038 safe.
> >>>
> >>> Build tests:
> >>> ./src/scripts/build-many-glibcs.py glibcs
> >>> ---
> >>>  time/stime.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/time/stime.c b/time/stime.c
> >>> index 576fa9c0c9..963902126b 100644
> >>> --- a/time/stime.c
> >>> +++ b/time/stime.c
> >>> @@ -27,11 +27,11 @@ int
> >>>  attribute_compat_text_section
> >>>  __stime (const time_t *when)
> >>>  {
> >>> -  struct timespec ts;
> >>> +  struct __timespec64 ts;
> >>>    ts.tv_sec = *when;
> >>>    ts.tv_nsec = 0;
> >>>  
> >>> -  return __clock_settime (CLOCK_REALTIME, &ts);
> >>> +  return __clock_settime64 (CLOCK_REALTIME, &ts);
> >>>  }
> >>>  
> >>>  compat_symbol (libc, __stime, stime, GLIBC_2_0);
> >>>     
> >>
> >> For !__ASSUME_TIME64_SYSCALLS builds time_t will continue to be 32
> >> bits and stime will continue to be non Y2038 safe.  
> > 
> > This patch is a preparatory work for introducing support of
> > -D_TIME_BITS=64 compilation flag when compiling programs with glibc
> > [1].
> > 
> > Then the __USE_TIME_BITS64 is defined for exported glibc headers.
> > After this the time_t will become __time64_t on e.g. ARM32 bits
> > (__WORDSIZE==32 && __TIMESIZE==32).> 
> > As pointed out by Joseph [3], without such code we will not be able
> > atomically introduce _TIME_BITS=64 support.  
> 
> The _TIME_BITS=64 is a redirection for programs build against the
> glibc provided headers, not for glibc build *itself*. Otherwise we
> will change the ABI depending of the minimum supported kernel (which
> might define __ASSUME_TIME64_SYSCALLS).
> 
> In this compatibility case we need to always assure the internal
> time_t is 32 bits to architecture that provided such interface.
> 
> 
> >   
> >>  Also, internally
> >> __clock_settime will first try to issue __NR_clock_settime64, so
> >> current code already accomplishes what this patch is aiming to do.
> >>  
> > 
> > There is a use case when we do need to call __clock_settime64
> > though:
> > 
> > - ARM32 program is compiled with -D_TIME_BITS=64
> > - The clock_settime (or stime) internally uses __clock_settime()
> > which in this case supports only 32 bit time API.  
> 
> Arm programs linked against old glibc will need to continue to call
> stime with time_t being 32-bits.  The stime won't be exported for
> -D_TIME_BITS=64, neither a stime64 will be implemented.

Ok.

> 
> > 
> >   To have this system Y2038 safe - one needs to call
> > __clock_settime64 explicitly to support passing arguments via
> > struct __timespec64.
> > 
> >   This is true for all calls of __clock_settime/__clock_gettime
> >   (functions to be used internally by glibc, as we ought to switch
> > to e.g. struct __timespec64).  
> 
> The idea of deprecate and make stime a compat symbol is exactly to
> avoid need to provide a Y2038 version of it. Newer programs that aim
> to be Y2038 safe will need to use clock_settime instead.

I've noted that stime is marked as "deprecated". If we can agree that
it will be removed from glibc soon (or at least before Y2038 :-)) or we
explicitly state that it will NOT be Y2038 safe, then indeed this patch
is not needed.

> 
> 
> > 
> > Links:
> > 
> > [1] -
> > https://github.com/lmajewski/y2038_glibc/commit/e03c7188c72dd78d7141cf88f24dd2a5fd14c4f1#diff-a5ab6c74681eaf0569ed54f6bf0d7978R386
> > 
> > [2] -
> > https://github.com/lmajewski/y2038_glibc/commit/e03c7188c72dd78d7141cf88f24dd2a5fd14c4f1#diff-c051022b496f12bd9028edb46b8ec04dR7
> > 
> > [3] - https://sourceware.org/ml/libc-alpha/2020-01/msg00369.html
> > 
> > [4] -
> > https://github.com/lmajewski/y2038_glibc/blob/glibc_settimeofday_64bit_conversion_v1/sysdeps/unix/sysv/linux/clock_settime.c#L57
> > 
> > 
> > 
> > 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 
>  


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
Adhemerval Zanella Jan. 21, 2020, 5:16 p.m. UTC | #5
On 21/01/2020 13:54, Lukasz Majewski wrote:
> Hi Adhemerval,
>>>   To have this system Y2038 safe - one needs to call
>>> __clock_settime64 explicitly to support passing arguments via
>>> struct __timespec64.
>>>
>>>   This is true for all calls of __clock_settime/__clock_gettime
>>>   (functions to be used internally by glibc, as we ought to switch
>>> to e.g. struct __timespec64).  
>>
>> The idea of deprecate and make stime a compat symbol is exactly to
>> avoid need to provide a Y2038 version of it. Newer programs that aim
>> to be Y2038 safe will need to use clock_settime instead.
> 
> I've noted that stime is marked as "deprecated". If we can agree that
> it will be removed from glibc soon (or at least before Y2038 :-)) or we
> explicitly state that it will NOT be Y2038 safe, then indeed this patch
> is not needed.

The stime prototype is not exported any longer, so newer programs trying
to use it against a future glibc with 64 bit time_t support will fail. We
can't remove compatibility symbols, so the only case I see that Y2038 safe
program to incorrectly use stime would be it define it itself with a
wrong signature (stime (time64_t)), which is outside the scope on how
glibc can mitigate it.

Patch
diff mbox series

diff --git a/time/stime.c b/time/stime.c
index 576fa9c0c9..963902126b 100644
--- a/time/stime.c
+++ b/time/stime.c
@@ -27,11 +27,11 @@  int
 attribute_compat_text_section
 __stime (const time_t *when)
 {
-  struct timespec ts;
+  struct __timespec64 ts;
   ts.tv_sec = *when;
   ts.tv_nsec = 0;
 
-  return __clock_settime (CLOCK_REALTIME, &ts);
+  return __clock_settime64 (CLOCK_REALTIME, &ts);
 }
 
 compat_symbol (libc, __stime, stime, GLIBC_2_0);