Messages in this thread | | | Date | Tue, 31 Jul 2012 07:31:00 -0400 | Subject | Re: [PATCH 0/2][RFC] Better handling of insane CMOS values | From | Josh Boyer <> |
| |
On Tue, Jul 31, 2012 at 2:35 AM, John Stultz <john.stultz@linaro.org> wrote: > So CAI Qian noticed recent boot trouble on a machine that had its CMOS > clock configured for the year 8200. > See: http://lkml.org/lkml/2012/7/29/188 > > While running with a crazy CMOS clock isn't advised, and a simple > "don't do that" might be reasonable, the behavior has in effect > regressed recently due to changes in the hrtimer/timekeeping > interactions. > > This patchset tries to resolve this issue in two ways: > 1) Change ktime_get_update_offsets to match ktime_get and avoid > possible precision loss with extremely large timespecs. > > 2) Catch any stop attempt to set the time to a value (circa the > year 2264) large enough to overflow ktime_t. > > The end fix here might be an either/or/both combination of these > two changes, so I wanted to send them out for comment. I'm also > looking at further ways to test and improve robustness around > these more extreme time values. > > I've also only been able to lightly test. If you want to try this out > you can add the following to timekeeping_init after the > read_persistent_clock() call: > > now.tv_sec = 196469280000LL; > > thanks > -john > > > Cc: Ingo Molnar <mingo@kernel.org> > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> > Cc: Prarit Bhargava <prarit@redhat.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Zhouping Liu <zliu@redhat.com> > Cc: CAI Qian <caiqian@redhat.com>
These should be CC'd to stable, right? CAI hit this with a 3.5-rcX kernel, and the hrtimer stuff was backported to 3.4 and before I thought.
josh
| |