[PATCH 1/2] time: Fix NTP adjustment mult overflow.

[pang.xunlei]

The mult memember of struct clocksource should always be a large u32 number when calculated through
__clocksource_updatefreq_scale(). The value of (cs->mult+cs->maxadj) may have a chance to reach very
near 0xFFFFFFFF. For instance, 555MHz oscillator: cs->mult is 0xE6A17102, cs->maxadj is 0x195E8EFD,
cs->mult+cs->maxadj is 0xFFFFFFFF. Such oscillators would probably exist on some processors like
MIPS which use CP0 compare/count CPU clock as the clock source.

Clocksource might encounter large frequency adjustment due to the hardware unstability, environment
temperature, software deviation, NTP algorithm accuracy, etc. When NTP slewes the clock, kernel goes
through update_wall_time()->...->timekeeping_apply_adjustment(): tk->tkr.mult += mult_adj;
Unfortunately, tk->tkr.mult may overflow after this operation, though such cases are next to impossible
to happen in practice.

This patch avoids mult overflow by judging the overflow case before adding mult_adj to mult, also adds the
WARNING message when capturing such case.

Signed-off-by: pang.xunlei <pang.xunlei@xxxxxxxxxx>
---
 kernel/time/timekeeping.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index ec1791f..cad61b3 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1332,6 +1332,12 @@ static __always_inline void timekeeping_apply_adjustment(struct timekeeper *tk,
 	 *
 	 * XXX - TODO: Doc ntp_error calculation.
 	 */
+	if (tk->tkr.mult + mult_adj < mult_adj) {
+		/* NTP adjustment caused clocksource mult overflow */
+		WARN_ON_ONCE(1);
+		return;
+	}
+
 	tk->tkr.mult += mult_adj;
 	tk->xtime_interval += interval;
 	tk->tkr.xtime_nsec -= offset;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/