[PATCH 0/6] Introduce 64bit accessors and structures required to address y2038 issues in the posix_clock subsystem

[PATCH 0/6] Introduce 64bit accessors and structures required to address y2038 issues in the posix_clock subsystem

[Baolin Wang]

This patch series change the 32-bit time types (timespec/itimerspec) to
the 64-bit types (timespec64/itimerspec64), and add new 64bit accessor
functions, which are required in order to avoid y2038 issues in the
posix_clock subsystem.

In order to avoid spamming people too much, I'm only sending the first
few patches of the patch series, and left the other patches for later.

And if you are interested in the whole patch series, see:
https://git.linaro.org/people/baolin.wang/upstream_0627.git

Thoughts and feedback would be appreciated.

Baolin Wang (6):
  time: Introduce struct itimerspec64
  timekeeping: Introduce current_kernel_time64()
  security: Introduce security_settime64()
  time: Introduce do_sys_settimeofday64()
  time: Introduce timespec64_to_jiffies()/jiffies_to_timespec64()
  cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

 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 +++++++++++++++
 include/linux/jiffies.h               |   22 ++++++++++++++++++---
 include/linux/lsm_hooks.h             |    5 +++--
 include/linux/security.h              |   20 ++++++++++++++++---
 include/linux/time64.h                |   35 +++++++++++++++++++++++++++++++++
 include/linux/timekeeping.h           |   24 +++++++++++++++++++---
 kernel/time/time.c                    |   28 +++++++++++++++-----------
 kernel/time/timekeeping.c             |    6 +++---
 security/commoncap.c                  |    2 +-
 security/security.c                   |    2 +-
 14 files changed, 148 insertions(+), 42 deletions(-)

-- 
1.7.9.5

[PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

[Baolin Wang]

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(-)

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 */
-- 
1.7.9.5

Re: [PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

[Thomas Gleixner]

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

Re: [PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

[Baolin Wang]

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


-- 
Baolin.wang
Best Regards

Re: [PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

[Thomas Gleixner]

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

Re: [PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

[Baolin Wang]

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



-- 
Baolin.wang
Best Regards

Re: [PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

[Thomas Gleixner]

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


   

Re: [PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()

[Baolin Wang]

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



-- 
Baolin.wang
Best Regards