Attachment 304882 Details for Bug 445713 – fix for tsc going back problem.

[patch] fix for tsc going back problem.

tsc-prevent-time-going-backwards-rhel.patch (text/plain), 4.24 KB, created by Alok Kataria on 2008-05-08 18:10:57 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Alok Kataria

Created: 2008-05-08 18:10:57 UTC

Size: 4.24 KB

patch

obsolete

>This is a backport of the patch submitted by Thomas Gleixner, which
>was merged upstream, commit d8bb6f4c1670c8324e4135c61ef07486f7f17379
>
>Clocksoruces were introduced only in i386 arch for 2.6.18 kernels.
>So this fix is only necessary for i386 code base.
>
>Patch on top of kernel-2.6.18-53.1.19.el5.
>
>Comments from the original post :
>
>We already catch most of the TSC problems by sanity checks, but there
>is a subtle bug which has been in the code for ever. This can cause
>time jumps in the range of hours.
>
>This was reported in:
>     http://lkml.org/lkml/2007/8/23/96
>and
>     http://lkml.org/lkml/2008/3/31/23
>
>I was able to reproduce the problem with a gettimeofday loop test on a
>dual core and a quad core machine which both have sychronized
>TSCs. The TSCs seems not to be perfectly in sync though, but the
>kernel is not able to detect the slight delta in the sync check. Still
>there exists an extremly small window where this delta can be observed
>with a real big time jump. So far I was only able to reproduce this
>with the vsyscall gettimeofday implementation, but in theory this
>might be observable with the syscall based version as well.
>
>CPU 0 updates the clock source variables under xtime/vyscall lock and
>CPU1, where the TSC is slighty behind CPU0, is reading the time right
>after the seqlock was unlocked.
>
>The clocksource reference data was updated with the TSC from CPU0 and
>the value which is read from TSC on CPU1 is less than the reference
>data. This results in a huge delta value due to the unsigned
>subtraction of the TSC value and the reference value. This algorithm
>can not be changed due to the support of wrapping clock sources like
>pm timer.
>
>The huge delta is converted to nanoseconds and added to xtime, which
>is then observable by the caller. The next gettimeofday call on CPU1
>will show the correct time again as now the TSC has advanced above the
>reference value.
>
>To prevent this TSC specific wreckage we need to compare the TSC value
>against the reference value and return the latter when it is larger
>than the actual TSC value.
>
>I pondered to mark the TSC unstable when the readout is smaller than
>the reference value, but this would render an otherwise good and fast
>clocksource unusable without a real good reason.
>
>Signed-off-by: Alok N Kataria <akataria@vmware.com>
>CC: Thomas Gleixner <tglx@linutronix.de>
>
>
>Index: linux-2.6.18.noarch/arch/i386/kernel/tsc.c
>===================================================================
>--- linux-2.6.18.noarch.orig/arch/i386/kernel/tsc.c	2008-05-07 14:12:57.000000000 -0700
>+++ linux-2.6.18.noarch/arch/i386/kernel/tsc.c	2008-05-07 14:59:14.000000000 -0700
>@@ -325,14 +325,27 @@
> 
> static unsigned long current_tsc_khz = 0;
> static int tsc_update_callback(void);
>+static struct clocksource clocksource_tsc;
> 
>+/*
>+ * We compare the TSC to the cycle_last value in the clocksource
>+ * structure to avoid a nasty time-warp issue. This can be observed in
>+ * a very small window right after one CPU updated cycle_last under
>+ * xtime lock and the other CPU reads a TSC value which is smaller
>+ * than the cycle_last reference value due to a TSC which is slighty
>+ * behind. This delta is nowhere else observable, but in that case it
>+ * results in a forward time jump in the range of hours due to the
>+ * unsigned delta calculation of the time keeping core code, which is
>+ * necessary to support wrapping clocksources like pm timer.
>+ */
> static cycle_t read_tsc(void)
> {
> 	cycle_t ret;
> 
> 	rdtscll(ret);
> 
>-	return ret;
>+	return ret >= clocksource_tsc.cycle_last ?
>+               ret : clocksource_tsc.cycle_last;
> }
> 
> static struct clocksource clocksource_tsc = {
>Index: linux-2.6.18.noarch/kernel/timer.c
>===================================================================
>--- linux-2.6.18.noarch.orig/kernel/timer.c	2008-05-07 14:13:15.000000000 -0700
>+++ linux-2.6.18.noarch/kernel/timer.c	2008-05-07 14:59:14.000000000 -0700
>@@ -1048,6 +1048,7 @@
> 	u64 nsec;
> 	new = clocksource_get_next();
> 	if (clock != new) {
>+		new->cycle_last = 0;
> 		now = clocksource_read(new);
> 		nsec =  __get_nsec_offset();
> 		timespec_add_ns(&xtime, nsec);
>@@ -1115,6 +1116,7 @@
> 
> 	write_seqlock_irqsave(&xtime_lock, flags);
> 	/* restart the last cycle value */
>+	clock->cycle_last = 0;
> 	clock->cycle_last = clocksource_read(clock);
> 	clock->error = 0;
> 	timekeeping_suspended = 0;

Actions: View | Diff

Attachments on bug 445713: 304882