RE: [chrony-dev] [PATCH] More reliable method of reading rtc for initial trim

["Hattink, Tjalling [FINT]" <T.Hattink@xxxxxxxx>]

> > When chrony reads in the linux rtc for the first time to trim the
> > system clock, it only reads it once. As it is possible that the rtc
> > updates itself during the read operation, the reported rtc time
could
> > be false. To prevent this I've added a loop that reads the rtc clock
> > twice, if the seconds do not match retry the two read operations. If
> > they match you can assume the read operation was successful.
> 
> Interesting, but I'm not sure I understand this correctly.
> 
> Are you saying that the RTC reading can be hh:mm:00 instead of
> hh:mm+1:00 when the minute rolls over after hh:mm:59? How do we know
> seconds are updated in RTC before minutes and that we can use the
first
> reading from two consecutive readings if they agree in seconds?
> Isn't it possible that the two readings will be hh:mm:00 and
> hh:mm+1:00 and we should use the second one?
> 

When the kernel rtc driver queries the rtc it has to issue multiple read
operations to get the data. It first reads the seconds, then minutes,
hours, etc.. You can see this happening in the kernel 3.10.34 at
drivers/char/rtc.c:1323-1331

The problem is that between these read operations the rtc hardware could
update itself by adding a second. For example, when the time is 10:59,
the first read will return 59 seconds, then rtc updates to 11:00, the
second read returns 11 minutes. So the resulting time is 11:59 instead
of 11:00. I've been able to see this behavior by continuously reading
the rtc clock. By reading in the clock twice the second readout will
have a different seconds value when the rtc updates itself somewhere
during the first and second read. When both reads are the same, you can
assume the rtc didn't update, and either read attempt should be fine.

The second location in chrony (in read_from_device) where the rtc is
read it waits until the rtc has generated an interrupt. So it should be
safe to read the rtc then as it has just been updated.

> > This is based on the hwclock implementation of reading the rtc clock
> > from the util-linux package.
> 
> I don't see this in the current util-linux hwclock code. There is a
> busy loop around ioctl(RTC_RD_TIME) to make the system clock reading
at
> the start of the RTC second, but it doesn't seem to be related to the
> problem you describe, or is it?
> 

I got it from
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/sys-uti
ls/hwclock-cmos.c?h=stable/v2.24