public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David P. Reed" <dpreed@reed.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RFC: do get_rtc_time() correctly
Date: Wed, 15 Aug 2007 20:26:41 -0400	[thread overview]
Message-ID: <46C399C1.9000502@reed.com> (raw)
In-Reply-To: <20070816005151.56176a04@the-village.bc.nu>

Alan:

Thanks for the comment. I will code a patch, and include a sanity check 
as you suggested, and send it for review. Just to clarify one concern 
your note raised:

I understand that SMM/SMI servicing can take a long time, but SMM/SMI 
shouldn't  happen while interrupts are masked using local_irq_disable() 
[included in spin_lock_irq()], at least on x86-architectures.  If 
SMM/SMI can happen even then, the NMI fix below could be generalized.

My mention of NMI (which by definition can't be masked) is because NMI 
can happen even while interrupts are masked.  This is a timing problem 
that can't be dealt with by masking interrupts, and NMI's are used for 
watchdogs, etc these days.   It seems like just a general good thing to 
be able to ask if an NMI has happened.   A per-cpu NMI eventcount that 
is incremented every NMI would allow one to detect NMI's that happen 
during an otherwise masked code sequence by reading it at the beginning 
and end of the code sequence.   Don't know if NMIs are common on other 
architectures, or if this is an architecture dependent concern.

Perhaps I'm really talking about two patches here.  One for a mechanism 
to detect NMIs that happen during a critical piece of code (so it can be 
retried), and one that depends on that to be really proper in reading 
the RTC reliably.

Alan Cox wrote:
>> So the proper way to read the RTC contents is to read the UIP flag, and 
>> if zero, read all the RTC registers with interrupts masked completely, 
>> so all reads happen in the 224 usec window.  (NMI can still be a 
>> problem, but you can have NMI's set a flag that forces a retry).
>>     
>
> SMM/SMI is more likely to be what bumps you 224usec or more.
>
>   
>> I'm happy to code and test a patch.   Rather than just submit a patch, I 
>> thought I'd request others' comments on this, since it affects so many 
>> architectures.  cc me, if you will, as I don't subscribe to LKML, just 
>> check it periodically.
>>     
>
> Go for it. The other architectures generally inherit it by inheriting
> similar bridge chips or in more modern times the RTC macrocell. It should
> also be possible to debug by putting in an optional sanity check
> initially which checks the read made sense compared to a few more
>
>   

  reply	other threads:[~2007-08-16  0:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-15 19:22 RFC: do get_rtc_time() correctly David P. Reed
2007-08-15 23:51 ` Alan Cox
2007-08-16  0:26   ` David P. Reed [this message]
2007-08-16  0:54     ` Rene Herman
2007-08-16 10:05     ` Alan Cox
2007-08-16  0:15 ` H. Peter Anvin

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=46C399C1.9000502@reed.com \
    --to=dpreed@reed.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /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