Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756122AbcK2HUJ (ORCPT ); Tue, 29 Nov 2016 02:20:09 -0500 Received: from mail-wj0-f194.google.com ([209.85.210.194]:34556 "EHLO mail-wj0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753188AbcK2HUA (ORCPT ); Tue, 29 Nov 2016 02:20:00 -0500 Date: Tue, 29 Nov 2016 08:19:55 +0100 From: Ingo Molnar To: John Stultz Cc: lkml , Chen Yu , "Rafael J. Wysocki" , Xunlei Pang , Ingo Molnar , Len Brown , "H. Peter Anvin" , Pavel Machek , Thomas Gleixner , Prarit Bhargava , Richard Cochran Subject: Re: [PATCH 2/7] timekeeping: Ignore the bogus sleep time if pm_trace is enabled Message-ID: <20161129071955.GB29412@gmail.com> References: <1480372524-15181-1-git-send-email-john.stultz@linaro.org> <1480372524-15181-3-git-send-email-john.stultz@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1480372524-15181-3-git-send-email-john.stultz@linaro.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2522 Lines: 80 * John Stultz wrote: > From: Chen Yu > > Previously we encountered some memory overflow issues due to > the bogus sleep time brought by inconsistent rtc, which is > triggered when pm_trace is enabled, and we have fixed it > in recent kernel. However it's improper in the first place > to call __timekeeping_inject_sleeptime() in case that pm_trace > is enabled simply because that "hash" time value will wreckage > the timekeeping subsystem. s/ Previously we encountered memory overflow issues due to bogus sleep time brought by an inconsistent RTC, which is triggered when pm_trace is enabled, and we have fixed it in recent kernels. However it's improper in the first place to call __timekeeping_inject_sleeptime() in case pm_trace is enabled simply because the "hash" time value will wreckage the timekeeping subsystem. Half a dozen typos ... > This patch is originally written by Thomas, which would bypass > the bogus rtc interval when pm_trace is enabled. > Meanwhile, if system succeed to resume back with pm_trace set, the > users are warned to adjust the bogus rtc either by 'ntpdate' or > 'rdate', by resetting pm_trace_rtc_abused to false, otherwise above > tools might not work as expected. s/ This patch was originally written by Thomas, which would bypass the bogus RTC interval when pm_trace is enabled. Meanwhile, if the system succeeds to resume back with pm_trace set, users are warned to adjust the bogus RTC either by 'ntpdate' or 'rdate', by resetting pm_trace_rtc_abused to false, otherwise above tools might not work as expected. > + /* > + * If pm_trace abused the RTC as storage set the timespec to 0 > + * which tells the caller that this RTC value is bogus. > + */ s/ /* * If pm_trace abused the RTC as storage, set the timespec to 0, * which tells the caller that this RTC value is bogus. */ > @@ -74,6 +75,9 @@ > > #define DEVSEED (7919) > > +bool pm_trace_rtc_abused __read_mostly; > +EXPORT_SYMBOL(pm_trace_rtc_abused); EXPORT_SYMBOL_GPL() > +static int pm_trace_notify(struct notifier_block *nb, > + unsigned long mode, void *_unused) Please no nonsensical linebreaks in the middle of an argument list. > +{ > + switch (mode) { > + case PM_POST_HIBERNATION: > + case PM_POST_SUSPEND: > + if (pm_trace_rtc_abused) { > + pm_trace_rtc_abused = false; > + pr_warn("Possible incorrect RTC due to pm_trace, please use 'ntpdate' or 'rdate' to reset.\n"); s/to reset./to reset it. Thanks, Ingo