On Fri, Dec 05, 2014 at 02:17:19PM -0800, Greg KH wrote: > On Fri, Nov 28, 2014 at 02:18:58AM +0000, xiaofeng.yan wrote: > > From: Stephen Boyd <[email protected]> > > > > There is a small race between when the cycle count is read from > > the hardware and when the epoch stabilizes. Consider this > > scenario: > > > > CPU0 CPU1 > > ---- ---- > > cyc = read_sched_clock() > > cyc_to_sched_clock() > > update_sched_clock() > > ... > > cd.epoch_cyc = cyc; > > epoch_cyc = cd.epoch_cyc; > > ... > > epoch_ns + cyc_to_ns((cyc - epoch_cyc) > > > > The cyc on cpu0 was read before the epoch changed. But we > > calculate the nanoseconds based on the new epoch by subtracting > > the new epoch from the old cycle count. Since epoch is most likely > > larger than the old cycle count we calculate a large number that > > will be converted to nanoseconds and added to epoch_ns, causing > > time to jump forward too much. > > > > Fix this problem by reading the hardware after the epoch has > > stabilized. > > > > Cc: Russell King <[email protected]> > > Signed-off-by: Stephen Boyd <[email protected]> > > Signed-off-by: John Stultz <[email protected]> > > --- > > kernel/time/sched_clock.c | 19 ++++++++----------- > > This file isn't even in the 3.10-stable kernel tree, so there is no way > you have tested this patch :(
arch/arm/kernel/sched_clock.c -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
