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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 12 Feb 2009 19:02:01 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Clark Williams <williams@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: [PATCH][RFC] Apply NTP frequency/tick changes immediately.

Hey Roman,
	It was brought to my attention that since the GENERIC_TIME changes
landed, the adjtimex behavior changed for struct timex.tick and .freq
changes. When the tick or freq value is set, we adjust the
tick_length_base in ntp_update_frequency(). However, this new value
doesn't get applied to tick_length until the next second (via
second_overflow). 

This means some applications that do quick time tweaking do not see the
requested change made as quickly as expected.

Looking at the code, it doesn't seem like it would be too hard to
immediately apply the change to the tick_length value, so its changed in
the following NTP_INTERVAL, which this patch does.

I've run a few tests with this change, and ntpd still functions fine. I
do however note that the drift value for my test system changed from
~170ppm to ~18ppm, which I didn't quite expect, and needs some
additional research.

Anyway, I just wanted to see if you had any thoughts on this sort of
change.

thanks
-john


Apply NTP tick/frequency adjustments immediately instead of waiting for
the next second to pass.

Signed-off-by: John Stultz <johnstul@...ibm.com>

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index f5f793d..9fd0d15 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -51,6 +51,7 @@ static long ntp_tick_adj;
 
 static void ntp_update_frequency(void)
 {
+	u64 old_tick_length_base = tick_length_base;
 	u64 second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ)
 				<< NTP_SCALE_SHIFT;
 	second_length += (s64)ntp_tick_adj << NTP_SCALE_SHIFT;
@@ -60,6 +61,11 @@ static void ntp_update_frequency(void)
 
 	tick_nsec = div_u64(second_length, HZ) >> NTP_SCALE_SHIFT;
 	tick_length_base = div_u64(tick_length_base, NTP_INTERVAL_FREQ);
+	
+	/* Don't wait for the next second_overflow, apply
+	 * the change to the tick length immediately
+	 */
+	tick_length += tick_length_base - old_tick_length_base;
 }
 
 static void ntp_update_offset(long offset)


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ