On Tue, 2014-03-04 at 14:40 +0800, John Stultz wrote: > On Tue, Mar 4, 2014 at 1:38 PM, Mike Galbraith <bitbuc...@online.de> wrote: > > (crap crap crap... M.A.I.N.T.A.I.N.E.R.S _dummy_) > > > > clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns() > > > > As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock", > > cycles * mult >> shift is overflow prone. so give it the same treatment. > > > > Cc: Salman Qazi <sq...@google.com> > > Cc: John Stultz <john.stu...@linaro.org>, > > Signed-off-by: Mike Galbraith <bitbuc...@online.de> > > Thanks for sending this in! Curious exactly how the issue was being > triggered?
Dunno that it is. This is the result of me rummaging around, looking for any excuse what-so-ever for a small and identical group of weird a$$ boxen running old 2.6.32 kernels (w. 208 day fix!) to manage to hop back and forth in time by exactly 208 days. Grep showed me that function, so I scurried off and swiped the fix. -Mike -- 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/
