From patchwork Wed May 4 03:11:48 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 1348 Return-Path: Delivered-To: unknown Received: from imap.gmail.com (74.125.159.109) by localhost6.localdomain6 with IMAP4-SSL; 08 Jun 2011 14:51:12 -0000 Delivered-To: patches@linaro.org Received: by 10.224.2.73 with SMTP id 9cs36319qai; Tue, 3 May 2011 20:12:04 -0700 (PDT) Received: by 10.90.136.1 with SMTP id j1mr623358agd.85.1304478723687; Tue, 03 May 2011 20:12:03 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by mx.google.com with ESMTPS id x10si1826651anx.159.2011.05.03.20.12.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 20:12:03 -0700 (PDT) Received-SPF: pass (google.com: domain of jstultz@us.ibm.com designates 32.97.182.146 as permitted sender) client-ip=32.97.182.146; Authentication-Results: mx.google.com; spf=pass (google.com: domain of jstultz@us.ibm.com designates 32.97.182.146 as permitted sender) smtp.mail=jstultz@us.ibm.com Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p442ljMN017518 for ; Tue, 3 May 2011 22:47:45 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p443Bv7Y103842 for ; Tue, 3 May 2011 23:11:57 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p443BvoC030311 for ; Tue, 3 May 2011 23:11:57 -0400 Received: from kernel.beaverton.ibm.com (kernel.beaverton.ibm.com [9.47.67.96]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p443Bv4U030265; Tue, 3 May 2011 23:11:57 -0400 Received: by kernel.beaverton.ibm.com (Postfix, from userid 1056) id 775511E750E; Tue, 3 May 2011 20:11:56 -0700 (PDT) From: John Stultz To: lkml Cc: John Stultz , Paul Mackerras , "Paul E. McKenney" , Anton Blanchard , Thomas Gleixner Subject: [PATCH] time: Add locking to xtime access in get_seconds() Date: Tue, 3 May 2011 20:11:48 -0700 Message-Id: <1304478708-1273-1-git-send-email-john.stultz@linaro.org> X-Mailer: git-send-email 1.7.3.2.146.gca209 From: John Stultz 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 CC: Paul E. McKenney CC: Anton Blanchard CC: Thomas Gleixner Signed-off-by: John Stultz --- 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);