linux-kernel - [tip:timers/urgent] time: Fix accumulation bug triggered by long delay.

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

Message-ID: <tip-830ec0458c390f29c6c99e1ff7feab9e36368d12@git.kernel.org>
Date:	Tue, 23 Mar 2010 15:42:43 GMT
From:	tip-bot for John Stultz <johnstul@...ibm.com>
To:	linux-tip-commits@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, hpa@...or.com, mingo@...hat.com,
	sonic.adi@...il.com, johnstul@...ibm.com, tglx@...utronix.de
Subject: [tip:timers/urgent] time: Fix accumulation bug triggered by long delay.

Commit-ID:  830ec0458c390f29c6c99e1ff7feab9e36368d12
Gitweb:     http://git.kernel.org/tip/830ec0458c390f29c6c99e1ff7feab9e36368d12
Author:     John Stultz <johnstul@...ibm.com>
AuthorDate: Thu, 18 Mar 2010 14:47:30 -0700
Committer:  Thomas Gleixner <tglx@...utronix.de>
CommitDate: Tue, 23 Mar 2010 16:41:01 +0100

time: Fix accumulation bug triggered by long delay.

The logarithmic accumulation done in the timekeeping has some overflow
protection that limits the max shift value. That means it will take
more then shift loops to accumulate all of the cycles. This causes
the shift decrement to underflow, which causes the loop to never exit.

The simplest fix would be simply to do a:
	if (shift)
		shift--;

However that is not optimal, as we know the cycle offset is larger
then the interval << shift, the above would make shift drop to zero,
then we would be spinning for quite awhile accumulating at interval
chunks at a time.

Instead, this patch only decreases shift if the offset is smaller
then cycle_interval << shift.  This makes sure we accumulate using
the largest chunks possible without overflowing tick_length, and limits
the number of iterations through the loop.

This issue was found and reported by Sonic Zhang, who also tested the fix.
Many thanks your explanation and testing!

Reported-by: Sonic Zhang <sonic.adi@...il.com>
Signed-off-by: John Stultz <johnstul@...ibm.com>
Tested-by: Sonic Zhang <sonic.adi@...il.com>
LKML-Reference: <1268948850-5225-1-git-send-email-johnstul@...ibm.com>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
---
 kernel/time/timekeeping.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 1673637..39f6177 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -818,7 +818,8 @@ void update_wall_time(void)
 	shift = min(shift, maxshift);
 	while (offset >= timekeeper.cycle_interval) {
 		offset = logarithmic_accumulation(offset, shift);
-		shift--;
+		if(offset < timekeeper.cycle_interval<<shift)
+			shift--;
 	}

 	/* correct the clock when NTP error is too big */
--
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/