All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <johnstul@us.ibm.com>
To: Kees Cook <keescook@chromium.org>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>,
	linux-kernel@vger.kernel.org, Colin Cross <ccross@android.com>,
	Tony Luck <tony.luck@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2] pstore/ram: no timekeeping calls when unavailable
Date: Mon, 19 Nov 2012 09:23:38 -0800	[thread overview]
Message-ID: <50AA6B1A.6060206@us.ibm.com> (raw)
In-Reply-To: <CAGXu5j+--cmhOHMR+7ewWt_ct-0p_o8sbK4bJWkgj067aeFjsw@mail.gmail.com>

On 11/18/2012 12:09 PM, Kees Cook wrote:
> On Fri, Nov 16, 2012 at 7:16 PM, John Stultz <johnstul@us.ibm.com> wrote:
>> Yea, I wanted to revisit this, because it is an odd case.
>>
>> We don't want to call getnstimeofday() while the timekeeping code is
>> suspended, since the clocksource cycle_last value may be invalid if the
>> hardware was reset during suspend.  Kees is correct,  the WARN_ONs were
>> there to make sure no one tries to use the timekeeping core before its
>> resumed, so removing them is problematic.
>>
>> Your sugggestion of having the __do_gettimeofday() internal accessor that
>> maybe returns an error if timekeeping has been suspended could work.
>>
>> The other possibility is depending on the needs for accuracy with the
>> timestamp, current_kernel_time() might be a better interface to use, since
>> it will return the time at the last tick, and doesn't require accessing the
>> clocksource hardware.  Might that be a simpler solution? Or is sub-tick
>> granularity necessary?
> I think it's only useful to have this to the same granularity as
> sched_clock(), so things can be correlated to dmesg output. If it's
> the same, I'd be fine to switch to using current_kernel_time().
Oof.  That's another can of worms,   sched_clock() resolution isn't tied 
to getnstimeofday(), since you may have cases where the TSC is invalid 
for timekeeping (so we use something slow like the ACPI PM) but ok for 
scheduling, etc.

Even so, its current_kernel_time() is just tick granularity, so that 
probably won't work for you.

So I'm leaning towards Anton's suggestion of adding a new internal 
accessor that returns an error if we're suspended.

Thomas, what do you think of something like what's below?

thanks
-john


diff --git a/include/linux/time.h b/include/linux/time.h
index 4d358e9..0015aea 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -158,6 +158,7 @@ extern int do_setitimer(int which, struct itimerval *value,
  			struct itimerval *ovalue);
  extern unsigned int alarm_setitimer(unsigned int seconds);
  extern int do_getitimer(int which, struct itimerval *value);
+extern int __getnstimeofday(struct timespec *tv);
  extern void getnstimeofday(struct timespec *tv);
  extern void getrawmonotonic(struct timespec *ts);
  extern void getnstime_raw_and_real(struct timespec *ts_raw,
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index e424970..bb2638c 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -220,19 +220,20 @@ static void timekeeping_forward_now(struct timekeeper *tk)
  }
  
  /**
- * getnstimeofday - Returns the time of day in a timespec
+ * __getnstimeofday - Returns the time of day in a timespec
   * @ts:		pointer to the timespec to be set
   *
- * Returns the time of day in a timespec.
+ * Returns -1 if timekeeping is suspended.
+ * Returns 0 on success.
   */
-void getnstimeofday(struct timespec *ts)
+int __getnstimeofday(struct timespec *ts)
  {
  	struct timekeeper *tk = &timekeeper;
  	unsigned long seq;
  	s64 nsecs = 0;
  
-	WARN_ON(timekeeping_suspended);
-
+	if (unlikely(timekeeping_suspended));
+		return -1;
  	do {
  		seq = read_seqbegin(&tk->lock);
  
@@ -243,6 +244,19 @@ void getnstimeofday(struct timespec *ts)
  
  	ts->tv_nsec = 0;
  	timespec_add_ns(ts, nsecs);
+	return 0;
+}
+EXPORT_SYMBOL(__getnstimeofday);
+
+/**
+ * getnstimeofday - Returns the time of day in a timespec
+ * @ts:		pointer to the timespec to be set
+ *
+ * Returns the time of day in a timespec.
+ */
+void getnstimeofday(struct timespec *ts)
+{
+	WARN_ON(__getnstimeofday(ts));
  }
  EXPORT_SYMBOL(getnstimeofday);
  


  reply	other threads:[~2012-11-19 17:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05 22:00 [PATCH v2] pstore/ram: no timekeeping calls when unavailable Kees Cook
2012-11-10  0:56 ` John Stultz
2012-11-10  1:26   ` Kees Cook
2012-11-17  2:53     ` Anton Vorontsov
2012-11-17  3:16       ` John Stultz
2012-11-18 20:09         ` Kees Cook
2012-11-19 17:23           ` John Stultz [this message]
2012-11-19 17:45             ` Kees Cook
2012-11-19 18:57               ` John Stultz
2012-11-19 21:42                 ` Kees Cook

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=50AA6B1A.6060206@us.ibm.com \
    --to=johnstul@us.ibm.com \
    --cc=anton.vorontsov@linaro.org \
    --cc=ccross@android.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.