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>] [day] [month] [year] [list]
Message-ID: <20150914210532.GA59490@google.com>
Date:	Mon, 14 Sep 2015 14:05:32 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	Michael Turquette <mturquette@...aro.org>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	Jim Quinlan <jim2101024@...il.com>,
	Gregory Fong <gregory.0xf0@...il.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	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

Hi Michael,

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.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ