From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: Justin Forbes <jmforbes@linuxtx.org>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
"Theodore Ts'o" <tytso@mit.edu>,
Randy Dunlap <rdunlap@xenotime.net>,
Dave Jones <davej@redhat.com>,
Chuck Wolber <chuckw@quantumlinux.com>,
torvalds@osdl.org, akpm@osdl.org, alan@lxorguk.ukuu.org.uk,
davem@davemloft.net, richm@oldelvet.org.uk
Subject: [patch 07/12] Fix timekeeping on sparc64 ultra-IIe machines
Date: Fri, 27 Jan 2006 18:21:12 -0800 [thread overview]
Message-ID: <20060128022112.GH17001@kroah.com> (raw)
In-Reply-To: <20060128022023.GA17001@kroah.com>
[-- Attachment #1: sparc64-fix-timekeeping-on-ultra-IIe-machines.patch --]
[-- Type: text/plain, Size: 3053 bytes --]
2.6.15.2 -stable review patch. If anyone has any objections, please let
us know.
------------------
From: Richard Mortimer <richm@oldelvet.org.uk>
[SPARC64]: Eliminate race condition reading Hummingbird STICK register
Ensure a consistent value is read from the STICK register by ensuring
that both high and low are read without high changing due to a roll
over of the low register.
Various Debian/SPARC users (myself include) have noticed problems with
Hummingbird based systems. The symptoms are that the system time is
seen to jump forward 3 days, 6 hours, 11 minutes give or take a few
seconds. In many cases the system then hangs some time afterwards.
I've spotted a race condition in the code to read the STICK register.
I could not work out why 3d, 6h, 11m is important but guess that it is
due to the 2^32 jump of STICK (forwards on one read and then the next
read will seem to be backwards) during a timer interrupt. I'm guessing
that a change of -2^32 will get converted to a large unsigned
increment after the arithmetic manipulation between STICK,
nanoseconds, jiffies etc.
I did a test where I modified __hbird_read_stick to artificially
inject rollover faults forcefully every few seconds. With this I saw
the clock jump over 6 times in 12 hours compared to once every month
or so.
Signed-off-by: Richard Mortimer <richm@oldelvet.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/sparc64/kernel/time.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
--- linux-2.6.15.1.orig/arch/sparc64/kernel/time.c
+++ linux-2.6.15.1/arch/sparc64/kernel/time.c
@@ -280,9 +280,9 @@ static struct sparc64_tick_ops stick_ope
* Since STICK is constantly updating, we have to access it carefully.
*
* The sequence we use to read is:
- * 1) read low
- * 2) read high
- * 3) read low again, if it rolled over increment high by 1
+ * 1) read high
+ * 2) read low
+ * 3) read high again, if it rolled re-read both low and high again.
*
* Writing STICK safely is also tricky:
* 1) write low to zero
@@ -295,18 +295,18 @@ static struct sparc64_tick_ops stick_ope
static unsigned long __hbird_read_stick(void)
{
unsigned long ret, tmp1, tmp2, tmp3;
- unsigned long addr = HBIRD_STICK_ADDR;
+ unsigned long addr = HBIRD_STICK_ADDR+8;
- __asm__ __volatile__("ldxa [%1] %5, %2\n\t"
- "add %1, 0x8, %1\n\t"
- "ldxa [%1] %5, %3\n\t"
+ __asm__ __volatile__("ldxa [%1] %5, %2\n"
+ "1:\n\t"
"sub %1, 0x8, %1\n\t"
+ "ldxa [%1] %5, %3\n\t"
+ "add %1, 0x8, %1\n\t"
"ldxa [%1] %5, %4\n\t"
"cmp %4, %2\n\t"
- "blu,a,pn %%xcc, 1f\n\t"
- " add %3, 1, %3\n"
- "1:\n\t"
- "sllx %3, 32, %3\n\t"
+ "bne,a,pn %%xcc, 1b\n\t"
+ " mov %4, %2\n\t"
+ "sllx %4, 32, %4\n\t"
"or %3, %4, %0\n\t"
: "=&r" (ret), "=&r" (addr),
"=&r" (tmp1), "=&r" (tmp2), "=&r" (tmp3)
--
next prev parent reply other threads:[~2006-01-28 2:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060128020629.908825000@press.kroah.org>
2006-01-28 2:20 ` [patch 00/12] 2.6.15.2 -stable review Greg KH
2006-01-28 2:20 ` [patch 01/12] usb-audio: don't use empty packets at start of playback Greg KH
2006-01-28 2:20 ` [patch 02/12] [BLOCK] Kill blk_attempt_remerge() Greg KH
2006-01-28 2:20 ` [patch 03/12] Input: HID - fix an oops in PID initialization code Greg KH
2006-01-28 2:20 ` [patch 04/12] Fix double decrement of mqueue_mnt->mnt_count in sys_mq_open (CVE-2005-3356) Greg KH
2006-01-28 2:20 ` [patch 05/12] Fix oops in ufs_fill_super at mount time Greg KH
2006-01-28 2:21 ` [patch 06/12] elevator=as back-compatibility Greg KH
2006-01-28 19:19 ` Jens Axboe
2006-01-31 7:09 ` [stable] " Greg KH
2006-01-28 2:21 ` Greg KH [this message]
2006-01-28 2:21 ` [patch 08/12] [NET]: Make second arg to skb_reserved() signed Greg KH
2006-01-28 2:21 ` [patch 09/12] Mask off GFP flags before swiotlb_alloc_coherent Greg KH
2006-01-28 2:33 ` Andi Kleen
2006-01-28 3:49 ` Andrew Morton
2006-01-28 6:04 ` Andi Kleen
2006-01-28 2:21 ` [patch 10/12] Someone broke reiserfs v3 mount options and this fixes it Greg KH
2006-01-28 2:21 ` [patch 11/12] Fix i2o_scsi oops on abort Greg KH
2006-01-28 2:21 ` [patch 12/12] Fix mkiss locking bug Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060128022112.GH17001@kroah.com \
--to=gregkh@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=chuckw@quantumlinux.com \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=jmforbes@linuxtx.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=richm@oldelvet.org.uk \
--cc=stable@kernel.org \
--cc=torvalds@osdl.org \
--cc=tytso@mit.edu \
--cc=zwane@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.