From: Thomas Gleixner <tglx@linutronix.de>
To: "David P. Reed" <dpreed@reed.com>
Cc: linux-kernel@vger.kernel.org,
Allessandro Zummo <a.zummo@towertech.it>,
Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH] x86: on x86_64, correct reading of PC RTC when update in progress in time_64.c
Date: Thu, 15 Nov 2007 20:33:54 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.0.9999.0711152021270.3112@localhost.localdomain> (raw)
In-Reply-To: <473B9D8A.5000006@reed.com>
On Wed, 14 Nov 2007, David P. Reed wrote:
Still whitespace wreckage in your patches. I guess the kernel tree you
made your patches against is already white space wrecked.
I fixed that up manually, but please be more careful about that next
time.
> Correct potentially unstable PC RTC time register reading in time_64.c
>
> Stop the use of an incorrect technique for reading the standard PC RTC
> timer, which is documented to "disconnect" time registers from the bus
> while updates are in progress. The use of UIP flag while interrupts
> are disabled to protect a 244 microsecond window is one of the
> Motorola spec sheet's documented ways to read the RTC time registers
> reliably.
>
> The patch updates the misleading comments and also minimizes the amount of
> time that the kernel disables interrupts during the reading.
While I think that the UIP change is correct and a must have, the
locking change is not really useful. read_persistent_clock is called
from exactly three places:
Right after boot, right before suspend and right after resume. None of
those places is a hot path, where we really care about the interrupt
enable/disable. IIRC, this is even called with interrupts disabled
most of the time, so no real gain here.
Another reason not to do the locking change is the paravirt stuff
which is coming for 64bit. I looked into the existing 32bit code and
doing the same lock thing would introduce a real nasty hackery, which
is definitely not worth the trouble.
Thanks,
tglx
> Signed-off-by: David P. Reed <dpreed@reed.com>
> ---
> Index: linux-2.6/arch/x86/kernel/time_64.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/time_64.c
> +++ linux-2.6/arch/x86/kernel/time_64.c
> @@ -160,22 +160,30 @@ unsigned long read_persistent_clock(void
> unsigned long flags;
> unsigned century = 0;
>
> - spin_lock_irqsave(&rtc_lock, flags);
> + retry: spin_lock_irqsave(&rtc_lock, flags);
> + /* if UIP is clear, then we have >= 244 microseconds before RTC
> + * registers will be updated. Spec sheet says that this is the
> + * reliable way to read RTC - registers invalid (off bus) during
> update
> + */
> + if ((CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)) {
> + spin_unlock_irqrestore(&rtc_lock, flags);
> + cpu_relax();
> + goto retry;
> + }
>
> - do {
> - sec = CMOS_READ(RTC_SECONDS);
> - min = CMOS_READ(RTC_MINUTES);
> - hour = CMOS_READ(RTC_HOURS);
> - day = CMOS_READ(RTC_DAY_OF_MONTH);
> - mon = CMOS_READ(RTC_MONTH);
> - year = CMOS_READ(RTC_YEAR);
> + /* now read all RTC registers while stable with interrupts disabled */
> +
> + sec = CMOS_READ(RTC_SECONDS);
> + min = CMOS_READ(RTC_MINUTES);
> + hour = CMOS_READ(RTC_HOURS);
> + day = CMOS_READ(RTC_DAY_OF_MONTH);
> + mon = CMOS_READ(RTC_MONTH);
> + year = CMOS_READ(RTC_YEAR);
> #ifdef CONFIG_ACPI
> - if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> - acpi_gbl_FADT.century)
> - century = CMOS_READ(acpi_gbl_FADT.century);
> + if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> + acpi_gbl_FADT.century)
> + century = CMOS_READ(acpi_gbl_FADT.century);
> #endif
> - } while (sec != CMOS_READ(RTC_SECONDS));
> -
> spin_unlock_irqrestore(&rtc_lock, flags);
>
> /*
>
>
next prev parent reply other threads:[~2007-11-15 19:34 UTC|newest]
Thread overview: 181+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <466F0941.9060201@reed.com>
[not found] ` <1181682498.8176.224.camel@chaos>
[not found] ` <469578CD.3080609@reed.com>
[not found] ` <1184216528.12353.203.camel@chaos>
[not found] ` <1184218962.12353.209.camel@chaos>
[not found] ` <46964352.7040301@reed.com>
[not found] ` <1184253339.12353.223.camel@chaos>
[not found] ` <469697C6.50903@reed.com>
[not found] ` <1184274754.12353.254.camel@chaos>
2007-11-12 16:55 ` [PATCH] x86: fix locking and sync bugs in x86_64 RTC code in time_64.c David P. Reed
2007-11-14 7:49 ` Thomas Gleixner
2007-11-14 13:10 ` David P. Reed
2007-11-14 18:26 ` Matt Mackall
2007-11-14 21:22 ` David P. Reed
2007-11-12 17:02 ` [PATCH] time: fix typo that makes sync_cmos_clock erratic David P. Reed
2007-11-14 7:57 ` Thomas Gleixner
2007-11-12 19:19 ` David P. Reed
2007-11-14 22:47 ` [PATCH] x86: fix freeze in x86_64 RTC update code in time_64.c David P. Reed
2007-11-14 22:49 ` [PATCH] time: fix typo that makes sync_cmos_clock erratic David P. Reed
2007-11-15 1:14 ` [PATCH] x86: on x86_64, correct reading of PC RTC when update in progress in time_64.c David P. Reed
2007-11-15 19:33 ` Thomas Gleixner [this message]
2007-11-15 20:31 ` David P. Reed
2007-11-15 22:17 ` Thomas Gleixner
2007-12-14 2:59 ` [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc David P. Reed
2007-12-14 7:49 ` Yinghai Lu
2007-12-14 9:45 ` Rene Herman
2007-12-14 14:23 ` Ingo Molnar
2007-12-14 14:36 ` Rene Herman
2007-12-14 14:46 ` Ingo Molnar
2007-12-14 14:56 ` Rene Herman
2007-12-14 18:36 ` Alan Cox
2007-12-14 18:48 ` H. Peter Anvin
2007-12-14 21:05 ` Pavel Machek
2007-12-15 22:59 ` Pavel Machek
2007-12-14 10:51 ` Andi Kleen
2007-12-14 11:11 ` David P. Reed
2007-12-14 13:15 ` Ingo Molnar
2007-12-14 13:24 ` Ingo Molnar
2007-12-14 13:47 ` Ingo Molnar
2007-12-14 14:41 ` Ingo Molnar
2007-12-14 13:42 ` Rene Herman
2007-12-14 14:03 ` Ingo Molnar
2007-12-14 14:10 ` Rene Herman
2007-12-14 14:21 ` Ingo Molnar
2007-12-14 18:02 ` H. Peter Anvin
2007-12-14 18:23 ` Rene Herman
2007-12-14 21:06 ` Pavel Machek
2007-12-14 22:13 ` H. Peter Anvin
2007-12-14 23:29 ` Alan Cox
2007-12-15 3:04 ` David P. Reed
2007-12-15 5:45 ` H. Peter Anvin
2007-12-15 17:17 ` David P. Reed
2007-12-15 17:46 ` Alan Cox
2007-12-17 22:50 ` Jan Engelhardt
2007-12-17 22:52 ` H. Peter Anvin
2007-12-15 8:08 ` Paul Rolland
2007-12-15 8:13 ` Rene Herman
2007-12-15 20:27 ` H. Peter Anvin
2007-12-15 23:26 ` [PATCH] x86: " Rene Herman
2007-12-15 23:51 ` H. Peter Anvin
2007-12-16 0:05 ` H. Peter Anvin
2007-12-16 13:15 ` [PATCH] x86: provide a DMI based port 0x80 I/O delay override Rene Herman
2007-12-16 15:22 ` Ingo Molnar
2007-12-17 1:43 ` Rene Herman
2007-12-17 2:05 ` H. Peter Anvin
2007-12-17 2:19 ` Rene Herman
2007-12-17 3:35 ` H. Peter Anvin
2007-12-17 13:02 ` Rene Herman
2007-12-17 17:14 ` H. Peter Anvin
2007-12-17 19:43 ` David P. Reed
2007-12-17 19:55 ` H. Peter Anvin
2007-12-17 21:02 ` David P. Reed
2007-12-17 21:17 ` H. Peter Anvin
2007-12-17 21:25 ` Alan Cox
2008-01-01 15:57 ` David P. Reed
2008-01-01 21:16 ` H. Peter Anvin
2008-01-01 15:59 ` David P. Reed
2008-01-01 16:15 ` Alan Cox
2008-01-01 16:43 ` Ingo Molnar
2008-01-01 17:32 ` Alan Cox
2008-01-01 18:45 ` Ingo Molnar
2008-01-01 20:14 ` Christer Weinigel
2008-01-01 21:13 ` Alan Cox
2008-01-01 21:07 ` Alan Cox
2008-01-02 10:04 ` Ingo Molnar
2008-01-02 13:11 ` [linux-kernel] " David P. Reed
2008-01-02 13:21 ` Ingo Molnar
2008-01-02 13:47 ` Alan Cox
2008-01-02 15:35 ` Rene Herman
2008-01-02 15:50 ` Rene Herman
2008-01-01 17:32 ` Christer Weinigel
2008-01-01 18:46 ` Ingo Molnar
2008-01-01 19:35 ` Christer Weinigel
2008-01-01 19:59 ` Rene Herman
2008-01-01 20:55 ` Christer Weinigel
2008-01-01 21:24 ` H. Peter Anvin
2008-01-01 21:01 ` Ingo Molnar
2008-01-01 21:26 ` Alan Cox
2008-01-01 21:42 ` Christer Weinigel
2008-01-01 21:42 ` Rene Herman
2008-01-01 21:50 ` H. Peter Anvin
2008-01-01 21:21 ` H. Peter Anvin
2008-01-01 23:05 ` Christer Weinigel
2008-01-01 23:12 ` Alan Cox
2008-01-02 0:23 ` Christer Weinigel
2008-01-02 10:00 ` Ingo Molnar
2008-01-01 17:32 ` David P. Reed
2008-01-01 17:38 ` Alan Cox
2008-01-01 21:15 ` H. Peter Anvin
2008-01-01 21:35 ` Rene Herman
2008-01-01 21:44 ` H. Peter Anvin
2008-01-01 22:35 ` Rene Herman
2008-01-01 22:39 ` H. Peter Anvin
2008-01-01 23:11 ` Rene Herman
2008-01-02 0:25 ` Rene Herman
2008-01-02 0:55 ` Christer Weinigel
2008-01-02 1:00 ` Rene Herman
2008-01-02 2:27 ` H. Peter Anvin
2008-01-09 17:27 ` Maciej W. Rozycki
2008-01-09 18:18 ` H. Peter Anvin
2008-01-01 17:31 ` Pavel Machek
2008-01-01 17:33 ` David P. Reed
2007-12-17 4:09 ` H. Peter Anvin
2007-12-17 10:57 ` Ingo Molnar
2007-12-17 11:29 ` Ingo Molnar
2007-12-17 13:34 ` David P. Reed
2007-12-17 12:15 ` Rene Herman
2007-12-17 13:09 ` Ingo Molnar
2007-12-17 13:22 ` Rene Herman
2007-12-17 13:31 ` Pavel Machek
2007-12-17 13:31 ` Rene Herman
2007-12-17 13:32 ` David P. Reed
2007-12-17 13:36 ` Rene Herman
2007-12-17 14:39 ` Ingo Molnar
2007-12-17 16:12 ` Alan Cox
2007-12-17 16:48 ` Ingo Molnar
2007-12-17 20:48 ` Rene Herman
2007-12-17 20:57 ` H. Peter Anvin
2007-12-17 21:33 ` Rene Herman
2007-12-17 21:40 ` H. Peter Anvin
2007-12-17 21:46 ` Ingo Molnar
2007-12-17 21:50 ` Rene Herman
2007-12-17 21:41 ` Ingo Molnar
2007-12-17 21:47 ` Rene Herman
2007-12-17 21:56 ` Ingo Molnar
2007-12-17 22:01 ` Rene Herman
2007-12-17 22:18 ` David P. Reed
2007-12-17 19:38 ` David P. Reed
2007-12-17 19:55 ` H. Peter Anvin
2007-12-17 21:28 ` Ingo Molnar
2007-12-16 21:42 ` H. Peter Anvin
2007-12-17 1:48 ` Rene Herman
2007-12-17 1:53 ` H. Peter Anvin
2007-12-16 23:12 ` David P. Reed
2007-12-17 1:56 ` Rene Herman
2007-12-17 2:04 ` H. Peter Anvin
2007-12-17 2:15 ` Rene Herman
2007-12-16 0:23 ` [PATCH] x86: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc David P. Reed
2007-12-15 20:26 ` [PATCH] x86_64: " H. Peter Anvin
2007-12-15 22:55 ` Pavel Machek
2007-12-16 9:27 ` Ingo Molnar
2007-12-17 21:04 ` Rene Herman
2007-12-17 23:20 ` Pavel Machek
2007-12-18 0:06 ` Alan Cox
2007-12-18 15:49 ` Lennart Sorensen
2007-12-17 22:46 ` Jan Engelhardt
2007-12-15 7:43 ` Ingo Molnar
2007-12-15 7:58 ` Rene Herman
2007-12-15 13:27 ` Ingo Molnar
2007-12-15 14:01 ` Rene Herman
2007-12-15 20:25 ` H. Peter Anvin
2007-12-15 14:29 ` Alan Cox
2007-12-15 16:19 ` David P. Reed
2007-12-15 16:48 ` Mark Lord
2007-12-15 17:51 ` Alan Cox
2007-12-15 23:00 ` Pavel Machek
2007-12-15 23:04 ` H. Peter Anvin
2007-12-16 9:40 ` Ingo Molnar
2007-12-16 21:43 ` H. Peter Anvin
2007-12-16 23:06 ` David P. Reed
2007-12-16 23:23 ` Pavel Machek
2007-12-16 23:34 ` H. Peter Anvin
2007-12-26 20:49 ` Pavel Machek
2007-12-17 1:51 ` Rene Herman
2007-12-14 16:08 ` Avi Kivity
2007-12-15 2:13 ` David P. Reed
2007-12-15 2:20 ` H. Peter Anvin
2007-12-17 18:14 ` linux-os (Dick Johnson)
2007-12-17 18:54 ` Rene Herman
2007-12-19 15:03 ` Avi Kivity
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=alpine.LFD.0.9999.0711152021270.3112@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=a.zummo@towertech.it \
--cc=dpreed@reed.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox