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]
Date:	Mon, 14 Sep 2015 16:08:40 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Brian Norris <computersforpeace@...il.com>
Cc:	Michael Turquette <mturquette@...libre.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Jim Quinlan <jim2101024@...il.com>,
	Gregory Fong <gregory.0xf0@...il.com>,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	u.kleine-koenig@...gutronix.de
Subject: Re: [PATCH] clk: divider: handle integer overflow when dividing
 large clock rates

On 09/14, Brian Norris wrote:
> (New address)
> 
> Hi Mike,
> 
> On Mon, Apr 27, 2015 at 08:49:10AM -0700, Michael Turquette wrote:
> > Quoting Michael Turquette (2015-04-14 15:11:37)
> > > Quoting Brian Norris (2015-04-13 16:03:21)
> > > > On 32-bit architectures, 'unsigned long' (the type used to hold clock
> > > > rates, in Hz) is often only 32 bits wide. DIV_ROUND_UP() (as used in,
> > > > e.g., commit b11d282dbea2 "clk: divider: fix rate calculation for
> > > > fractional rates") can yield an integer overflow on clock rates that are
> > > > not (by themselves) too large to fit in 32 bits, because it performs
> > > > addition before the division. See for example:
> > > > 
> > > >   DIV_ROUND_UP(3000000000, 1500000000) = (3.0G + 1.5G - 1) / 1.5G
> > > >                                        = OVERFLOW / 1.5G
> > > > 
> > > > This patch fixes such cases by always promoting the dividend to 64-bits
> > > > (unsigned long long) before doing the division. While this patch does
> > > > not resolve the issue with large clock rates across the common clock
> > > > framework nor address the problems with doing full 64-bit arithmetic on
> > > > a 32-bit architecture, it does fix some issues seen when using clock
> > > > dividers on a 3GHz reference clock to produce a 1.5GHz CPU clock for an
> > > > ARMv7 Brahma B15 SoC.
> > > > 
> > > > Signed-off-by: Brian Norris <computersforpeace@...il.com>
> > > > Reference: lkml.kernel.org/g/20150413201433.GQ32500@...irv-0074
> > > > ---
> > > > I'll admit I only compile-tested this particular patch. I have tested a version
> > > > of this patch on top of a few backports on an older kernel, and everything
> > > > works fine. Unforunately, some of my SoC's clock drivers still rely on
> > > > out-of-tree code.
> > > 
> > > I smoke tested this on some hardware and it seemed fine to me. I'll give
> > > some time for others to comment, otherwise I'll take this for 4.2 after
> > > -rc1 drops.
> > 
> > Applied to clk-next.
> 
> I was rebasing my old patches onto Linus' latest, and I noticed that
> this one never got in.
> 

Odd. I've thrown it into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ