public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: John Stultz <john.stultz@linaro.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] clocksource, Add warning to clocksource_delta() validation code
Date: Sat, 18 Oct 2014 07:06:46 -0400	[thread overview]
Message-ID: <544249C6.2040407@redhat.com> (raw)
In-Reply-To: <CALAqxLVZbqOBf7Xd5k4_euPxNLztHjmEubZys8iL4U9t9CPabQ@mail.gmail.com>



On 10/17/2014 02:27 PM, John Stultz wrote:
> On Fri, Oct 17, 2014 at 11:23 AM, Prarit Bhargava <prarit@redhat.com> wrote:
>>
>>
>> On 10/17/2014 02:17 PM, John Stultz wrote:
>>> On Fri, Oct 17, 2014 at 6:57 AM, Prarit Bhargava <prarit@redhat.com> wrote:
>>>> A bug report came in against an older kernel which output "backward time"
>>>> messages and the report noted that the upstream kernel worked.  After some
>>>> investigation it turned out that one of the sockets was bad on the system
>>>> and the "backward time" messages were caused by a real, but intermittent,
>>>> hardware failure.
>>>>
>>>> Commit 09ec54429c6d10f87d1f084de53ae2c1c3a81108 ("clocksource: Move
>>>> cycle_last validation to core code") modifies the x86 clocksource such that
>>>> if a negative delta between two reads of time is calculated the
>>>> clocksource_delta() code will return 0.  There is no warning when this
>>>> occurs and there really should be one in order to catch not only hardware
>>>> issues like the issue above, but potential coding issues as the code is
>>>> modified.  This patch introduces a WARN() which will also dump a stack
>>>> trace to the console so the exact code path can be evaluated.
>>>>
>>>> I tested this by booting on the broken hardware and left the system idle
>>>> until a negative clocksource_delta() event occurred.
>>>>
>>>> Cc: John Stultz <john.stultz@linaro.org>
>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>>>> ---
>>>>  kernel/time/timekeeping_internal.h |    7 ++++++-
>>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/kernel/time/timekeeping_internal.h b/kernel/time/timekeeping_internal.h
>>>> index 4ea005a..abe6bc8 100644
>>>> --- a/kernel/time/timekeeping_internal.h
>>>> +++ b/kernel/time/timekeeping_internal.h
>>>> @@ -17,7 +17,12 @@ static inline cycle_t clocksource_delta(cycle_t now, cycle_t last, cycle_t mask)
>>>>  {
>>>>         cycle_t ret = (now - last) & mask;
>>>>
>>>> -       return (s64) ret > 0 ? ret : 0;
>>>> +       if ((s64)ret > 0)
>>>> +               return ret;
>>>> +
>>>> +       WARN(1, "Clocksource calculated negative delta, %lld.  last = %llu, now = %llu, mask = %llx\n",
>>>> +            (s64)ret, last, now, mask);
>>>> +       return 0;
>>>
>>>
>>> I realize you followed up that this wasn't finished, but just as some
>>> feedback, there's a number of types of hardware where there may be a
>>> very slight skew between cpu TSC, and this will briefly trigger right
>>> after each timekeeping update if a system is reading the clock
>>> frequently (think of the case where the update happens on the cpu
>>> thats just a little bit ahead, while a timestamping loop is running on
>>> a cpu that is a little bit behind).
>>
>> Ah, interesting.  Okay ... drop this patch then.  Thanks for the info John.
> 
> If you're wanting something that aids with debugging, maybe some sort
> calmly stated warn-once in the dmesg might be ok, that or some other
> flag exported via a debugging interface.

IMO with the clock code I'd prefer it to be 100% accurate.  There is nothing
more annoying than going through the rigors of debugging and discovering that it
is a hardware issue of some sort... This can be dropped IMO.  It's really not
that important.

P.
> 
> thanks
> -john
> 

      reply	other threads:[~2014-10-18 11:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-17 13:57 [PATCH] clocksource, Add warning to clocksource_delta() validation code Prarit Bhargava
2014-10-17 17:23 ` Prarit Bhargava
2014-10-17 18:17 ` John Stultz
2014-10-17 18:23   ` Prarit Bhargava
2014-10-17 18:27     ` John Stultz
2014-10-18 11:06       ` Prarit Bhargava [this message]

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=544249C6.2040407@redhat.com \
    --to=prarit@redhat.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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