Re: RFC: do get_rtc_time() correctly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux