Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754928AbbGPKpE (ORCPT ); Thu, 16 Jul 2015 06:45:04 -0400 Received: from www.linutronix.de ([62.245.132.108]:41665 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751282AbbGPKpB (ORCPT ); Thu, 16 Jul 2015 06:45:01 -0400 Date: Thu, 16 Jul 2015 12:43:58 +0200 (CEST) From: Thomas Gleixner To: Baolin Wang cc: benh@kernel.crashing.org, Arnd Bergmann , John Stultz , peterz@infradead.org, paulus@samba.org, mpe@ellerman.id.au, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, linux390@de.ibm.com, rth@twiddle.net, riel@redhat.com, cl@linux.com, tj@kernel.org, =?ISO-8859-15?Q?Fr=E9d=E9ric_Weisbecker?= , linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-arch@vger.kernel.org, LKML , y2038 Mailman List Subject: Re: [PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime() In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2460 Lines: 66 On Thu, 16 Jul 2015, Baolin Wang wrote: > On 15 July 2015 at 19:55, Thomas Gleixner wrote: > > On Wed, 15 Jul 2015, Baolin Wang wrote: > > > >> On 15 July 2015 at 18:31, Thomas Gleixner 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/