On 2014/12/6 17:57, Russell King - ARM Linux wrote:
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 <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 :(
arch/arm/kernel/sched_clock.c
Sorry for my fault. I have submitted my patch and had a test for this
bug, Please check it with
title "[PATCH][request for stable inclusion][3.10.x]: ARM:
sched_clock: Load cycle count after epoch stabilizes"
Thanks
Yan
--
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