linux-kernel - [PATCH] time: fix typo that makes sync_cmos

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4738872D.7020706@reed.com>
Date:	Mon, 12 Nov 2007 12:02:37 -0500
From:	"David P. Reed" <dpreed@...d.com>
To:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
CC:	Allessandro Zummo <a.zummo@...ertech.it>
Subject: [PATCH] time: fix typo that makes sync_cmos_clock erratic

From: David P. Reed

Fix a typo in ntp.c that has caused updating of the persistent (RTC) 
clock when synced to NTP to behave erratically.

Signed-off-by: David P. Reed

---
When debugging a freeze that arises on my AMD64 machines when I run the 
ntpd service, I added a number of printk's to monitor the 
sync_cmos_clock procedure.  I discovered that it was not syncing to cmos 
RTC every 11 minutes as documented, but instead would keep trying every 
second for hours at a time.   The reason turned out to be a typo in 
sync_cmos_clock, where it attempts to ensure that 
update_persistent_clock is called very close to 500 msec. after a 1 
second boundary (required by the PC RTC's spec). That typo referred to 
"xtime" in one spot, rather than "now", which is derived from "xtime" 
but not equal to it.  This makes the test erratic, creating a 
"coin-flip" that decides when update_persistent_clock is called - when 
it is called, which is rarely, it may be at any time during the one 
second period, rather than close to 500 msec, so the value written is 
needlessly incorrect, too.

I rewrote the code to fix the typo and to be a little more clear about 
the logic that was intended here.  I have thoroughly tested this on 
several x86_64 machines, and also on one 32-bit machine.  I have also 
submitted a patch to fix the freeze cited above, but both patches are 
independent, and should be treated separately.

The patch works in 2.6.24rc2, but it should also work in 2.6.23.

Index: linux-2.6/kernel/time/ntp.c
===================================================================
--- linux-2.6.orig/kernel/time/ntp.c
+++ linux-2.6/kernel/time/ntp.c
@@ -188,6 +188,7 @@ static DEFINE_TIMER(sync_cmos_timer, syn
 static void sync_cmos_clock(unsigned long dummy)
 {
     struct timespec now, next;
+    long delta_from_target_time;
     int fail = 1;
 
     /*
@@ -205,7 +206,10 @@ static void sync_cmos_clock(unsigned lon
         return;
 
     getnstimeofday(&now);
-    if (abs(xtime.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec / 2)
+    delta_from_target_time = abs(now.tv_nsec - (NSEC_PER_SEC / 2));
+
+    /* set CMOS clock, only if close enough to 500 msec point */
+    if (delta_from_target_time <= tick_nsec / 2)
         fail = update_persistent_clock(now);
 
     next.tv_nsec = (NSEC_PER_SEC / 2) - now.tv_nsec;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/