[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1507151226210.18576@nanos>
Date: Wed, 15 Jul 2015 12:31:23 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Baolin Wang <baolin.wang@...aro.org>
cc: benh@...nel.crashing.org, arnd@...db.de, john.stultz@...aro.org,
peterz@...radead.org, paulus@...ba.org, mpe@...erman.id.au,
schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
linux390@...ibm.com, rth@...ddle.net, riel@...hat.com,
cl@...ux.com, tj@...nel.org, fweisbec@...il.com,
linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
y2038@...ts.linaro.org
Subject: Re: [PATCH 6/6] cputime: Introduce
cputime_to_timespec64()/timespec64_to_cputime()
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists