From: Daniel Thompson <daniel.thompson@linaro.org>
To: Andrew Morton <akpm@linux-foundation.org>, Arnd Bergmann <arnd@arndb.de>
Cc: Jason Wessel <jason.wessel@windriver.com>,
Thomas Gleixner <tglx@linutronix.de>,
y2038@lists.linaro.org, John Stultz <john.stultz@linaro.org>,
Stephen Boyd <sboyd@codeaurora.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Deepa Dinamani <deepa.kernel@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org,
kgdb-bugreport@lists.sourceforge.net
Subject: Re: [PATCH] kdb: use __ktime_get_real_seconds instead of __current_kernel_time
Date: Fri, 13 Oct 2017 09:26:17 +0100 [thread overview]
Message-ID: <c085cdc3-4e40-3c79-fdfa-a07511859313@linaro.org> (raw)
In-Reply-To: <20171012154032.24a3007c479154d77c2767b4@linux-foundation.org>
On 12/10/17 23:40, Andrew Morton wrote:
> On Thu, 12 Oct 2017 16:06:11 +0200 Arnd Bergmann <arnd@arndb.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.
next prev parent reply other threads:[~2017-10-13 8:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 14:06 Arnd Bergmann
2017-10-12 22:40 ` Andrew Morton
2017-10-13 8:26 ` Daniel Thompson [this message]
2017-12-06 21:39 ` Jason Wessel
2017-12-06 21:50 ` Jason Wessel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c085cdc3-4e40-3c79-fdfa-a07511859313@linaro.org \
--to=daniel.thompson@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=deepa.kernel@gmail.com \
--cc=jason.wessel@windriver.com \
--cc=john.stultz@linaro.org \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=tglx@linutronix.de \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®