Received: by 10.66.85.133 with SMTP id h5mr2184999paz.23.1353831846622;
        Sun, 25 Nov 2012 00:24:06 -0800 (PST)
Path: 6ni10248pbd.1!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nac.net!news.mi.ras.ru!goblin2!goblin1!goblin.stu.neva.ru!news.panservice.it!bofh.it!news.nic.it!robomod
From: Kees Cook <keesc...@chromium.org>
Newsgroups: linux.kernel
Subject: Re: [PATCH v2] pstore/ram: no timekeeping calls when unavailable
Date: Sun, 18 Nov 2012 21:10:02 +0100
Message-ID: <k7jlM-ca-7@gated-at.bofh.it>
References: <k2D1L-2TX-13@gated-at.bofh.it> <k483w-1Gm-37@gated-at.bofh.it> <k483w-1Gm-35@gated-at.bofh.it> <k6GNr-3vN-1@gated-at.bofh.it> <k6H6N-494-3@gated-at.bofh.it>
X-Original-To: John Stultz <johns...@us.ibm.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        bh=MsLCn5LUZV00DEsiFWvM8VBfMp2lK8tPTbNBf4P+IYQ=;
        b=RI12qeyJH75l/poWXRUIhEZmciOglOqou03amwh4DksZ7TYsU7KM/vnKIIz4IqicJM
         t9qcVrX6GfIACCl2nFZkigGIB6/og/G6dGWkG3fjZxZzD7NgMnnczKP3/YofR/0QCJeD
         1yH0TT/ogZ9aOjuXXmVLVy/WP2J/y3hJRMFuyQwkJ7ecUyY7YILNIERk+MSFX606V3An
         vqpUwMRZSVntqNej8Io4Ga2FIy+SBFN3gnwlGAyBkbepI3dRSxZajvGs4F7zBZCQXbcS
         gL0jQgjvbtKeKtbePa3RcPwj4gSzPkcelAGc5iyOAtKWw9D1FktmwKRK+cMP6//gQfcf
         Js3Q==
        d=google.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :x-gm-message-state;
        bh=MsLCn5LUZV00DEsiFWvM8VBfMp2lK8tPTbNBf4P+IYQ=;
        b=P1AMfjwkEPu4kywh7RgpajZJNd3ZkyzPdrFMtR1zUwhtUADBGEUo8yHt4Sm7av7yQ1
         85J2DpVOY1VMpe8idfCWYH3cg6/EQMIk9cDbqHDXSA/2hgaVS4IuPuyFsLFLqnDSbqoM
         0Yvu/mql02IOEBUG7J6gMKWctKMgux3/dfGsVEKfACaL7o+nHAX6fnM3qVpUdBg+BZZ3
         1EpMuuoJ7QThMFGiqg36iFmZ6UuL49JLFnNj00m7CHheEfBCLsY71JuPHhTfXQJXn26Q
         HoHSuD0/WNa3i93NNoDdquyLEU5UZ0UZp7aKftn+ra8cF1xePESiDQSgkpIlC+RxQmVp
         AxOw==
MIME-Version: 1.0
X-Gm-Message-State: ALoCoQmKVWKH8AUYr4hyev7g8lwMwOqiTPRtEBDUYiLm40INBnlrt0OpegQGIdJdFJN8k3BPAIypz5t9NyW8sIS5QyAH7cjJzl6eVEi4gRX0yZ1wNF7M8WOsXq1HAihF9A60OZStWNXiSzSvVC/pkj9a92P87R220siED7KQaI45hP/f8FLOGzLgQW4yhaq+BzFQOf8VAsGoh1OkO57WyB80w+e5A3JnUg==
Sender: robo...@news.nic.it
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-ker...@vger.kernel.org
Approved: robo...@news.nic.it
Lines: 32
Organization: linux.* mail to news gateway
X-Original-Cc: Anton Vorontsov <anton.voront...@linaro.org>,
	linux-ker...@vger.kernel.org, Colin Cross <ccr...@android.com>,
	Tony Luck <tony.l...@intel.com>,
	Thomas Gleixner <t...@linutronix.de>
X-Original-Date: Sun, 18 Nov 2012 12:09:16 -0800
X-Original-Message-ID: <CAGXu5j+--cmhOHMR+7ewWt_ct-0p_o8sbK4bJWkgj067aeF...@mail.gmail.com>
X-Original-References: <20121105220059.GA6...@www.outflux.net>
	<509DA63E.7070...@us.ibm.com>
	<CAGXu5jKq0=+XfH6yDSaJMcd-S3=o7xB67kspPkCRcXjRSGg...@mail.gmail.com>
	<20121117025355.GC29966@lizard>
	<50A70199.9030...@us.ibm.com>
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
Bytes: 4750
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 16, 2012 at 7:16 PM, John Stultz <johns...@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().

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/