On 2014/11/28 0:15, Greg KH wrote:
On Thu, Nov 27, 2014 at 11:15:36AM +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 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
What is the git commit id of this patch in Linus's tree?
yes
And what stable tree(s) do you want it applied to?
Thanks for your reminder, I will add stable tree information.
thanks,
greg k-h
.
--
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
