[PATCH] time: Add locking to xtime access in get_seconds()

[John Stultz]

From: John Stultz <johnstul@xxxxxxxxxx>

So get_seconds() has always been lock free, with the assumption
that accessing a long will be atomic.

However, recently I came across an odd bug where time() access could
occasionally be inconsistent, but only on power7 hardware. The
same code paths on power6 or x86 could not reproduce the issue.

After adding careful debugging checks to any xtime manipulation, and
not seeing any inconsistencies on the kernel side, I realized that
with no locking in the get_seconds path, its could be that two
sequential calls to time() could be executed out of order on newer
hardware, causing the inconsistency to appear in userland.

After adding the following locking, the issue cannot be reproduced.

Wanted to run this by the power guys to make sure the theory above
sounds sane.

CC: Paul Mackerras <paulus@xxxxxxxxx>
CC: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
CC: Anton Blanchard <anton@xxxxxxxxx>
CC: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Signed-off-by: John Stultz <johnstul@xxxxxxxxxx>
---
 kernel/time/timekeeping.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 8ad5d57..89c7582 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -975,7 +975,15 @@ EXPORT_SYMBOL_GPL(monotonic_to_bootbased);
 
 unsigned long get_seconds(void)
 {
-	return xtime.tv_sec;
+	unsigned long seq, now;
+
+	do {
+		seq = read_seqbegin(&xtime_lock);
+
+		now = xtime.tv_sec;
+	} while (read_seqretry(&xtime_lock, seq));
+
+	return now;
 }
 EXPORT_SYMBOL(get_seconds);
 
-- 
1.7.3.2.146.gca209

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/