[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c085cdc3-4e40-3c79-fdfa-a07511859313@linaro.org>
Date: Fri, 13 Oct 2017 09:26:17 +0100
From: Daniel Thompson <daniel.thompson@...aro.org>
To: Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>
Cc: Jason Wessel <jason.wessel@...driver.com>,
Thomas Gleixner <tglx@...utronix.de>, y2038@...ts.linaro.org,
John Stultz <john.stultz@...aro.org>,
Stephen Boyd <sboyd@...eaurora.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Deepa Dinamani <deepa.kernel@...il.com>,
Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
kgdb-bugreport@...ts.sourceforge.net
Subject: Re: [PATCH] kdb: use __ktime_get_real_seconds instead of
__current_kernel_time
On 12/10/17 23:40, Andrew Morton wrote:
> On Thu, 12 Oct 2017 16:06:11 +0200 Arnd Bergmann <arnd@...db.de> wrote:
>
>> kdb is the only user of the __current_kernel_time() interface, which is
>> not y2038 safe and should be removed at some point.
>>
>> The kdb code also goes to great lengths to print the time in a
>> human-readable format from 'struct timespec', again using a non-y2038-safe
>> re-implementation of the generic time_to_tm() code.
>
> Is it really necessary for the kdb `summary' command to print the
> time/date? Which puppies would die if we just removed it all?
kdb may enter spontaneously (BUG(), etc) so it can be useful if one
returns from an overnight test run to know how long things survived.
It would almost certainly be possible for a skilled user to reconstruct
the time of death. Having said that, one of the things you can do with
kdb (although I admit *I* have never done it) is leave a macro command
in the hands of an unskilled user.
Short summary: no puppies would die, but perhaps some might go hungry
for a little while when their owner is late home?
Daniel.
Powered by blists - more mailing lists