| Message ID | a1bd8d71caeb4051d0be87aad1baae7ababa4df7.1436511577.git.baolin.wang@linaro.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Wed, 15 Jul 2015, Baolin Wang wrote: > The cputime_to_timespec() and timespec_to_cputime() functions are > not year 2038 safe on 32bit systems due to that the struct timepsec > will overflow in 2038 year. And how is this relevant? cputime is not based on wall clock time at all. So what has 2038 to do with cputime? We want proper explanations WHY we need such a change. Thanks, tglx
On 15 July 2015 at 18:31, Thomas Gleixner <tglx@linutronix.de> wrote: > On Wed, 15 Jul 2015, Baolin Wang wrote: > >> The cputime_to_timespec() and timespec_to_cputime() functions are >> not year 2038 safe on 32bit systems due to that the struct timepsec >> will overflow in 2038 year. > > And how is this relevant? cputime is not based on wall clock time at > all. So what has 2038 to do with cputime? > > We want proper explanations WHY we need such a change. When converting the posix-cpu-timers, it call the cputime_to_timespec() function. Thus it need a conversion for this function. You can see that conversion in patch "posix-cpu-timers: Convert to y2038 safe callbacks" from https://git.linaro.org/people/baolin.wang/upstream_0627.git. And I also will explain this in the changelog. Thanks for your comments. > > Thanks, > > tglx > >
On Wed, 15 Jul 2015, Baolin Wang wrote: > On 15 July 2015 at 18:31, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Wed, 15 Jul 2015, Baolin Wang wrote: > > > >> The cputime_to_timespec() and timespec_to_cputime() functions are > >> not year 2038 safe on 32bit systems due to that the struct timepsec > >> will overflow in 2038 year. > > > > And how is this relevant? cputime is not based on wall clock time at > > all. So what has 2038 to do with cputime? > > > > We want proper explanations WHY we need such a change. > > When converting the posix-cpu-timers, it call the > cputime_to_timespec() function. Thus it need a conversion for this > function. There is no requirement to convert posix-cpu-timers on their own. We need to adopt the posix cpu timers code because it shares syscalls with the other posix timers, but that still does not explain why we need these functions. > You can see that conversion in patch "posix-cpu-timers: Convert to > y2038 safe callbacks" from > https://git.linaro.org/people/baolin.wang/upstream_0627.git. I do not care about your random git tree. I care about proper changelogs. Your changelogs are just a copied boilerplate full of errors. Thanks, tglx
On 15 July 2015 at 19:55, Thomas Gleixner <tglx@linutronix.de> wrote: > On Wed, 15 Jul 2015, Baolin Wang wrote: > >> On 15 July 2015 at 18:31, Thomas Gleixner <tglx@linutronix.de> wrote: >> > On Wed, 15 Jul 2015, Baolin Wang wrote: >> > >> >> The cputime_to_timespec() and timespec_to_cputime() functions are >> >> not year 2038 safe on 32bit systems due to that the struct timepsec >> >> will overflow in 2038 year. >> > >> > And how is this relevant? cputime is not based on wall clock time at >> > all. So what has 2038 to do with cputime? >> > >> > We want proper explanations WHY we need such a change. >> >> When converting the posix-cpu-timers, it call the >> cputime_to_timespec() function. Thus it need a conversion for this >> function. > > There is no requirement to convert posix-cpu-timers on their own. We > need to adopt the posix cpu timers code because it shares syscalls > with the other posix timers, but that still does not explain why we > need these functions. > In posix-cpu-timers, it also defined some 'k_clock struct' variables, and we need to convert the callbacks of the 'k_clock struct' which are not year 2038 safe on 32bit systems. Some callbacks which need to convert call the cputime_to_timespec() function, thus we also want to convert the cputime_to_timespec() function to a year 2038 safe function to make all them ready for the year 2038 issue. >> You can see that conversion in patch "posix-cpu-timers: Convert to >> y2038 safe callbacks" from >> https://git.linaro.org/people/baolin.wang/upstream_0627.git. > > I do not care about your random git tree. I care about proper > changelogs. Your changelogs are just a copied boilerplate full of > errors. > > Thanks, > > tglx
On Thu, 16 Jul 2015, Baolin Wang wrote: > On 15 July 2015 at 19:55, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Wed, 15 Jul 2015, Baolin Wang wrote: > > > >> On 15 July 2015 at 18:31, Thomas Gleixner <tglx@linutronix.de> wrote: > >> > On Wed, 15 Jul 2015, Baolin Wang wrote: > >> > > >> >> The cputime_to_timespec() and timespec_to_cputime() functions are > >> >> not year 2038 safe on 32bit systems due to that the struct timepsec > >> >> will overflow in 2038 year. > >> > > >> > And how is this relevant? cputime is not based on wall clock time at > >> > all. So what has 2038 to do with cputime? > >> > > >> > We want proper explanations WHY we need such a change. > >> > >> When converting the posix-cpu-timers, it call the > >> cputime_to_timespec() function. Thus it need a conversion for this > >> function. > > > > There is no requirement to convert posix-cpu-timers on their own. We > > need to adopt the posix cpu timers code because it shares syscalls > > with the other posix timers, but that still does not explain why we > > need these functions. > > > > In posix-cpu-timers, it also defined some 'k_clock struct' variables, > and we need to convert the callbacks of the 'k_clock struct' which are > not year 2038 safe on 32bit systems. Some callbacks which need to > convert call the cputime_to_timespec() function, thus we also want to > convert the cputime_to_timespec() function to a year 2038 safe > function to make all them ready for the year 2038 issue. You are not getting it at all. 1) We need to change k_clock callbacks due to 2038 issues 2) posix cpu timers implement affected callbacks 3) posix cpu timers themself and cputime are NOT affected by 2038 So we have 2 options to change the code in posix cpu timers: A) Do the timespec/timespec64 conversion in the posix cpu timer callbacks and leave the cputime functions untouched. B) Implement cputime/timespec64 functions to avoid #A If you go for #B, you need to provide a reasonable explanation why it is better than #A. And that explanation has absolutely nothing to do with 2038 safety. Not everything is a 2038 issue, just because the only tool you have is a timespec64. Thanks, tglx
On 16 July 2015 at 18:43, Thomas Gleixner <tglx@linutronix.de> wrote: > On Thu, 16 Jul 2015, Baolin Wang wrote: >> On 15 July 2015 at 19:55, Thomas Gleixner <tglx@linutronix.de> wrote: >> > On Wed, 15 Jul 2015, Baolin Wang wrote: >> > >> >> On 15 July 2015 at 18:31, Thomas Gleixner <tglx@linutronix.de> wrote: >> >> > On Wed, 15 Jul 2015, Baolin Wang wrote: >> >> > >> >> >> The cputime_to_timespec() and timespec_to_cputime() functions are >> >> >> not year 2038 safe on 32bit systems due to that the struct timepsec >> >> >> will overflow in 2038 year. >> >> > >> >> > And how is this relevant? cputime is not based on wall clock time at >> >> > all. So what has 2038 to do with cputime? >> >> > >> >> > We want proper explanations WHY we need such a change. >> >> >> >> When converting the posix-cpu-timers, it call the >> >> cputime_to_timespec() function. Thus it need a conversion for this >> >> function. >> > >> > There is no requirement to convert posix-cpu-timers on their own. We >> > need to adopt the posix cpu timers code because it shares syscalls >> > with the other posix timers, but that still does not explain why we >> > need these functions. >> > >> >> In posix-cpu-timers, it also defined some 'k_clock struct' variables, >> and we need to convert the callbacks of the 'k_clock struct' which are >> not year 2038 safe on 32bit systems. Some callbacks which need to >> convert call the cputime_to_timespec() function, thus we also want to >> convert the cputime_to_timespec() function to a year 2038 safe >> function to make all them ready for the year 2038 issue. > > You are not getting it at all. > > 1) We need to change k_clock callbacks due to 2038 issues > > 2) posix cpu timers implement affected callbacks > > 3) posix cpu timers themself and cputime are NOT affected by 2038 > > So we have 2 options to change the code in posix cpu timers: > > A) Do the timespec/timespec64 conversion in the posix cpu timer > callbacks and leave the cputime functions untouched. > > B) Implement cputime/timespec64 functions to avoid #A > > If you go for #B, you need to provide a reasonable explanation why > it is better than #A. And that explanation has absolutely nothing > to do with 2038 safety. Very thanks for your explanation, and I'll think about that. > > Not everything is a 2038 issue, just because the only tool you have is > a timespec64. > > Thanks, > > tglx > > >
diff --git a/arch/powerpc/include/asm/cputime.h b/arch/powerpc/include/asm/cputime.h index e245255..5dda5c0 100644 --- a/arch/powerpc/include/asm/cputime.h +++ b/arch/powerpc/include/asm/cputime.h @@ -154,9 +154,9 @@ static inline cputime_t secs_to_cputime(const unsigned long sec) } /* - * Convert cputime <-> timespec + * Convert cputime <-> timespec64 */ -static inline void cputime_to_timespec(const cputime_t ct, struct timespec *p) +static inline void cputime_to_timespec64(const cputime_t ct, struct timespec64 *p) { u64 x = (__force u64) ct; unsigned int frac; @@ -168,7 +168,7 @@ static inline void cputime_to_timespec(const cputime_t ct, struct timespec *p) p->tv_nsec = x; } -static inline cputime_t timespec_to_cputime(const struct timespec *p) +static inline cputime_t timespec64_to_cputime(const struct timespec64 *p) { u64 ct; diff --git a/arch/s390/include/asm/cputime.h b/arch/s390/include/asm/cputime.h index 221b454..3319b51 100644 --- a/arch/s390/include/asm/cputime.h +++ b/arch/s390/include/asm/cputime.h @@ -81,16 +81,16 @@ static inline cputime_t secs_to_cputime(const unsigned int s) } /* - * Convert cputime to timespec and back. + * Convert cputime to timespec64 and back. */ -static inline cputime_t timespec_to_cputime(const struct timespec *value) +static inline cputime_t timespec64_to_cputime(const struct timespec64 *value) { unsigned long long ret = value->tv_sec * CPUTIME_PER_SEC; return (__force cputime_t)(ret + __div(value->tv_nsec * CPUTIME_PER_USEC, NSEC_PER_USEC)); } -static inline void cputime_to_timespec(const cputime_t cputime, - struct timespec *value) +static inline void cputime_to_timespec64(const cputime_t cputime, + struct timespec64 *value) { unsigned long long __cputime = (__force unsigned long long) cputime; value->tv_nsec = (__cputime % CPUTIME_PER_SEC) * NSEC_PER_USEC / CPUTIME_PER_USEC; diff --git a/include/asm-generic/cputime_jiffies.h b/include/asm-generic/cputime_jiffies.h index fe386fc..54e034c 100644 --- a/include/asm-generic/cputime_jiffies.h +++ b/include/asm-generic/cputime_jiffies.h @@ -44,12 +44,12 @@ typedef u64 __nocast cputime64_t; #define secs_to_cputime(sec) jiffies_to_cputime((sec) * HZ) /* - * Convert cputime to timespec and back. + * Convert cputime to timespec64 and back. */ -#define timespec_to_cputime(__val) \ - jiffies_to_cputime(timespec_to_jiffies(__val)) -#define cputime_to_timespec(__ct,__val) \ - jiffies_to_timespec(cputime_to_jiffies(__ct),__val) +#define timespec64_to_cputime(__val) \ + jiffies_to_cputime(timespec64_to_jiffies(__val)) +#define cputime_to_timespec64(__ct,__val) \ + jiffies_to_timespec64(cputime_to_jiffies(__ct),__val) /* * Convert cputime to timeval and back. diff --git a/include/asm-generic/cputime_nsecs.h b/include/asm-generic/cputime_nsecs.h index 0419485..c0cafc0 100644 --- a/include/asm-generic/cputime_nsecs.h +++ b/include/asm-generic/cputime_nsecs.h @@ -71,14 +71,14 @@ typedef u64 __nocast cputime64_t; (__force cputime_t)((__secs) * NSEC_PER_SEC) /* - * Convert cputime <-> timespec (nsec) + * Convert cputime <-> timespec64 (nsec) */ -static inline cputime_t timespec_to_cputime(const struct timespec *val) +static inline cputime_t timespec64_to_cputime(const struct timespec64 *val) { u64 ret = val->tv_sec * NSEC_PER_SEC + val->tv_nsec; return (__force cputime_t) ret; } -static inline void cputime_to_timespec(const cputime_t ct, struct timespec *val) +static inline void cputime_to_timespec64(const cputime_t ct, struct timespec64 *val) { u32 rem; diff --git a/include/linux/cputime.h b/include/linux/cputime.h index f2eb2ee..cd638a0 100644 --- a/include/linux/cputime.h +++ b/include/linux/cputime.h @@ -13,4 +13,20 @@ usecs_to_cputime((__nsecs) / NSEC_PER_USEC) #endif +static inline cputime_t timespec_to_cputime(const struct timespec *ts) +{ + struct timespec64 ts64 = timespec_to_timespec64(*ts); + + return timespec64_to_cputime(&ts64); +} + +static inline void cputime_to_timespec(const cputime_t cputime, + struct timespec *value) +{ + struct timespec64 ts64; + + cputime_to_timespec64(cputime, &ts64); + *value = timespec64_to_timespec(ts64); +} + #endif /* __LINUX_CPUTIME_H */
The cputime_to_timespec() and timespec_to_cputime() functions are not year 2038 safe on 32bit systems due to that the struct timepsec will overflow in 2038 year. This patch introduces cputime_to_timespec64() and timespec64_to_cputime() functions which use struct timespec64. And converts arch specific implementations in arch/s390 and arch/powerpc. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> --- arch/powerpc/include/asm/cputime.h | 6 +++--- arch/s390/include/asm/cputime.h | 8 ++++---- include/asm-generic/cputime_jiffies.h | 10 +++++----- include/asm-generic/cputime_nsecs.h | 6 +++--- include/linux/cputime.h | 16 ++++++++++++++++ 5 files changed, 31 insertions(+), 15 deletions(-)