Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755908AbbGQIji (ORCPT ); Fri, 17 Jul 2015 04:39:38 -0400 Received: from mail-yk0-f174.google.com ([209.85.160.174]:34756 "EHLO mail-yk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752398AbbGQIjd (ORCPT ); Fri, 17 Jul 2015 04:39:33 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 17 Jul 2015 16:39:32 +0800 Message-ID: Subject: Re: [PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime() From: Baolin Wang To: Thomas Gleixner 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, =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-arch@vger.kernel.org, LKML , y2038 Mailman List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2705 Lines: 76 On 16 July 2015 at 18:43, Thomas Gleixner wrote: > 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. 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 -- 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/