On Tue, Jul 31, 2012 at 2:35 AM, John Stultz <john.stu...@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 <mi...@kernel.org> > Cc: Peter Zijlstra <a.p.zijls...@chello.nl> > Cc: Prarit Bhargava <pra...@redhat.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Zhouping Liu <z...@redhat.com> > Cc: CAI Qian <caiq...@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 -- 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/
