[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <m2mx1qlk4i.fsf@igel.home>
Date: Sun, 19 Aug 2012 22:09:01 +0200
From: Andreas Schwab <schwab@...ux-m68k.org>
To: John Stultz <john.stultz@...aro.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Prarit Bhargava <prarit@...hat.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: [PATCH] time: Fix casting issue in timekeeping_forward_now
arch_gettimeoffset returns a u32 value which when shifted by tk->shift can
overflow. Cast it to u64 first.
Signed-off-by: Andreas Schwab <schwab@...ux-m68k.org>
---
Found this by inspection, I don't know if any existing users of
ARCH_USES_GETTIMEOFFSET are affected. In other words, this is untested,
but looks pretty obvious.
Can tk->shift be bigger than 30? If so then the shifts in
update_wall_time need to be adjusted as well.
Andreas.
---
kernel/time/timekeeping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index e16af19..8776d66 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -276,7 +276,7 @@ static void timekeeping_forward_now(struct timekeeper *tk)
tk->xtime_nsec += cycle_delta * tk->mult;
/* If arch requires, add in gettimeoffset() */
- tk->xtime_nsec += arch_gettimeoffset() << tk->shift;
+ tk->xtime_nsec += (u64)arch_gettimeoffset() << tk->shift;
tk_normalize_xtime(tk);
--
1.7.11.5
--
Andreas Schwab, schwab@...ux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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