linux-kernel - clk: clock rates can overflow 32-bit fields

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

Date:	Sun, 12 Apr 2015 21:24:22 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	Mike Turquette <mturquette@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux PM mailing list <linux-pm@...r.kernel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Jim Quinlan <jim2101024@...il.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Gregory Fong <gregory.0xf0@...il.com>
Subject: clk: clock rates can overflow 32-bit fields

Hi,

I've recently been looking at using the common clock framework to
handle my CPU clocks for use by the cpufreq-dt driver, and I ran
across a few problems with integer overflow. On a 32-bit system,
'unsigned long' (the type used in clk_set_rate() and similar APIs) is
often a 32-bit integer. This constrains the maximum clock frequency to
~4.3 GHz, which is sufficient for most CPUs these days. However, I've
run into problems with high clock rates in the common clock framework
when

(1) using clk-divider.c; and/or
(2) using intermediate clocks that run faster than 4.3 GHz

With clk-divider.c, we can run into problems at lower clock rates due
to the usage of DIV_ROUND_UP (see, e.g., commit b11d282dbea2 "clk:
divider: fix rate calculation for fractional rates"), since this might
create overflows when doing the addition -- e.g., DIV_ROUND_UP(3 G,
1.5 G) = (3 G + 1.5 G - 1) / 1.5 G = (OVERFLOW) / 1.5 G

I could probably fix up the clk-divider.c issue locally, if necessary.
But problem (2) seems to suggest a larger change may be required
throughout the framework, and I'd like to solicit opinions before
hacking away.

So, any thoughts on how to best tackle this problem? Should we upgrade
the clock framework to use a guaranteed 64-bit type for clock rates
(e.g., u64)? I'm not sure if this will yield problems on certain
32-bit architectures when we start doing 64-bit integer division. But
I don't have many other great ideas at the moment...

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