| Message ID | 20200118072047.23071-2-lukma@denx.de |
|---|---|
| State | Superseded |
| Headers |
Received: (qmail 59117 invoked by alias); 18 Jan 2020 07:21:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 59034 invoked by uid 89); 18 Jan 2020 07:21:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy= X-HELO: mail-out.m-online.net From: Lukasz Majewski <lukma@denx.de> To: Joseph Myers <joseph@codesourcery.com>, Paul Eggert <eggert@cs.ucla.edu>, Adhemerval Zanella <adhemerval.zanella@linaro.org>, Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Alistair Francis <alistair23@gmail.com>, Alistair Francis <alistair.francis@wdc.com>, GNU C Library <libc-alpha@sourceware.org>, Siddhesh Poyarekar <siddhesh@gotplt.org>, Florian Weimer <fweimer@redhat.com>, Florian Weimer <fw@deneb.enyo.de>, Zack Weinberg <zackw@panix.com>, Carlos O'Donell <carlos@redhat.com>, Andreas Schwab <schwab@suse.de>, Lukasz Majewski <lukma@denx.de> Subject: [PATCH 1/6] y2038: Use __clock_settime64 in deprecated stime function Date: Sat, 18 Jan 2020 08:20:42 +0100 Message-Id: <20200118072047.23071-2-lukma@denx.de> In-Reply-To: <20200118072047.23071-1-lukma@denx.de> References: <20200118072047.23071-1-lukma@denx.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit |
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
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.
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
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 >
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
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.
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);