From: "David P. Reed" <dpreed@reed.com>
To: Thomas Gleixner <tglx@linutronix.de>
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 15:31:37 -0500 [thread overview]
Message-ID: <473CACA9.2090702@reed.com> (raw)
In-Reply-To: <alpine.LFD.0.9999.0711152021270.3112@localhost.localdomain>
There are a couple of things I don't understand on this one. And I
presume you thought the other two bug fixing patches I sent before this
were OK to go, since on my system
Thomas Gleixner 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.
Um ... I fixed the whitespaces I detected from the first round with
checkpatch.pl. Then for good measure
I ran checkpatch.pl on the patches, then pasted the files directly into
the emails. No problems detected.
And I also just tried checkpatch.pl on the "sent" folder copy. No
problems detected there.
Where was the whitespace? Was it in the patches? Would you mind showing
me the output so I can do a better job in the future?
>
>> 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:
>
What locking change? I didn't change how locking works in
read_persistent_clock at all.
I did introduce cpu_relax() because if anyone else ever calls from a hot
path, that would be good practice and its' one line.
> 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.
>
I presume time_64.c and time_32.c will be unified at some point,
discarding time_64.c. There's no arch-specific reason to be separate.
The current time_32.c depends on a different nmi path (that does some
weird stuff saving and restoring the CMOS index register!), and I didn't
dare usurp your long-term plan to unify architectures. But a simple
cleanup here makes sense, lest someone copy the bad technique as if it
were good.
> 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 20:31 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
2007-11-15 20:31 ` David P. Reed [this message]
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=473CACA9.2090702@reed.com \
--to=dpreed@reed.com \
--cc=a.zummo@towertech.it \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).