On Fri, Nov 28, 2014 at 02:18:58AM +0000, xiaofeng.yan wrote: > From: Stephen Boyd <sboyd@xxxxxxxxxxxxxx> > > 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 <linux@xxxxxxxxxxxxxxxx> > Signed-off-by: Stephen Boyd <sboyd@xxxxxxxxxxxxxx> > Signed-off-by: John Stultz <john.stultz@xxxxxxxxxx> > --- > 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 :( -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html