From: John Stultz <john.stultz@linaro.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Prarit Bhargava <prarit@redhat.com>,
Zhouping Liu <zliu@redhat.com>, CAI Qian <caiqian@redhat.com>
Subject: Re: [PATCH 1/2] [RFC] time: Fix problem with large timespecs & ktime_get_update_offsets
Date: Wed, 01 Aug 2012 09:49:36 -0700 [thread overview]
Message-ID: <50195E20.90704@linaro.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1208010850510.32033@ionos>
On 07/31/2012 11:52 PM, Thomas Gleixner wrote:
> On Tue, 31 Jul 2012, John Stultz wrote:
>> There's currently a slight difference in ktime_get_update_offsets()
>> vs ktime_get() which can result in boot time crashes when booting
>> with insane CMOS clock values larger then ~2264.
>>
>> ktime_get() does basically the following:
>> return timespec_to_ktime(timespec_add(xtime, wall_to_monotonic))
>>
>> Where as ktime_get_update_offsets does approximately:
>> return ktime_sub(timespec_to_ktime(xtime), realtime_offset);
>>
>> The problem is, at boot we set xtime = year 8200 and
>> wall_to_monotonic = year -8200, ktime_get adds both values, mostly
>> nulling the difference out (leaving only how long the system has been
>> up), then converts that relatively small value to a ktime_t properly
>> without losing any information.
>>
>> ktime_get_update_offsets however, since it converts xtime (again set
>> to some value greater then year 8200), to a ktime, it gets clamped at
>> KTIME_MAX, then we subtract realtime_offset, which is _also_ clamped
>> at KTIME_MAX, resulting in us always returning almost[1] zero. This
>> causes us to stop expiring timers.
>>
>> Now, one of the reasons Thomas and I changed the logic was that using
>> the precalculated realtime_offset was slightly more efficient then
>> re-adding xtime and wall_to_monotonic's components separately. But
>> how valuable this unmeasured slight efficiency is vs extra
>> robustness for crazy time values is questionable.
>>
>> So switch back to the ktime_get implementation for
>> ktime_get_update_offsets
> NAK.
>
> You're papering over the real problem: Using crap values without
> sanity checking them in the first place.
>
> All your patch does is papering over the problem. Heck, year 8200 is
> obvious bullshit, so we can detect and reject it.
Ok, sounds good. I'll drop this one and just keep the sanity checking patch.
thanks
-john
next prev parent reply other threads:[~2012-08-01 16:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 6:35 [PATCH 0/2][RFC] Better handling of insane CMOS values John Stultz
2012-07-31 6:35 ` [PATCH 1/2] [RFC] time: Fix problem with large timespecs & ktime_get_update_offsets John Stultz
2012-08-01 6:52 ` Thomas Gleixner
2012-08-01 16:49 ` John Stultz [this message]
2012-07-31 6:35 ` [PATCH 2/2] [RFC] time: Limit time values that would overflow ktime_t John Stultz
2012-07-31 9:54 ` [PATCH 0/2][RFC] Better handling of insane CMOS values James Courtier-Dutton
2012-07-31 16:57 ` John Stultz
2012-07-31 11:31 ` Josh Boyer
2012-07-31 16:36 ` John Stultz
2012-07-31 17:41 ` Prarit Bhargava
2012-07-31 17:47 ` John Stultz
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=50195E20.90704@linaro.org \
--to=john.stultz@linaro.org \
--cc=a.p.zijlstra@chello.nl \
--cc=caiqian@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=prarit@redhat.com \
--cc=tglx@linutronix.de \
--cc=zliu@redhat.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.