msm: timer: Fix racy sched_clock last_ns behavior
Previously we would use the global last_ns variable as a temporary
variable to hold the value we read from the timer. This is racy because
there is no locking and the other cpu can also manipulate last_ns,
causing sched_clock to appear to have jumped backwards. Fix this by
using a local variable for temporary data, and only accessing last_ns
once.
Change-Id: I881d5795c8a339e4baae928f1eb2493b35b88d65
Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 90a1c7e..7e61e8b 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -939,15 +939,17 @@
* Store the most recent timestamp read from hardware
* in last_ns. This is useful for debugging crashes.
*/
-static u64 last_ns;
+static atomic64_t last_ns;
unsigned long long notrace sched_clock(void)
{
struct msm_clock *clock = &msm_clocks[msm_global_timer];
struct clocksource *cs = &clock->clocksource;
- u32 cyc = cs->read(cs);
- last_ns = cyc_to_sched_clock(&cd, cyc, ((u32)~0 >> clock->shift));
- return last_ns;
+ u64 cyc = cs->read(cs);
+ u64 last_ns_local;
+ last_ns_local = cyc_to_sched_clock(&cd, cyc, ((u32)~0 >> clock->shift));
+ atomic64_set(&last_ns, last_ns_local);
+ return last_ns_local;
}
static void notrace msm_update_sched_clock(void)