linux-kernel - Re: [RFC] HZ free ntp

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 02 Jan 2007 12:50:52 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] HZ free ntp

On Tue, 2007-01-02 at 11:46 -0800, john stultz wrote:
> On Mon, 2007-01-01 at 19:29 +0100, Roman Zippel wrote:
> > On Wednesday 20 December 2006 02:54, john stultz wrote:
> > 
> > > And here would be the follow on patch (again *untested*) for
> > > CONFIG_NO_HZ slowing the time accumulation down to once per second.
> > 
> > Changing it to one creates a potential problem with calling second_overflow().

Wait, at first I thought I understood this, but looking closer, I'm not
so sure I do.

> > It should be called every NTP_INTERVAL_FREQ times, but occasionally it's off

Wait, so second_overflow should be called every NTP_INTERVAL_FREQ times
(instead of every second)? Surely that's not right.

> > by one (when xtime is close to a full second and the tick length is different
> > from 1sec). At a higher frequency that's not much of a problem, but at one it
> > means second_overflow() is occasionally called twice a second or skipped for
> > a second. Usually the error should be quite small, but sometimes it can be
> > significant.
> > So in this case the loop in update_wall_time() should rather look like this:
> > 
> > 	while (offset >= clock->cycle_interval) {
> > 		...
> > 		second_overflow();
> > 		while (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) {
> > 			clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift;
> > 			xtime.tv_sec++;
> > 		}
> > 		...
> > 	}
> > 
> > (Also note the change from "if" to "while".)

This would assume that clock->cycle_interval would *always* be the
length of a full second and that isn't what the patch trying to do.

Maybe could you explain this some more?

thanks
-john


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