Re: [PATCH]: fix 32bits integer overflow in loops_per_jiffy calculation

Gabriel Paubert
2002-08-22T10:44:16Z

Yoann Vandoorselaere wrote:
> Hi,
>
> The "low_part * mult" multiplication of the old function may overflow a
> 32bits integer...
>
> This patch both fix the overflow issue (tested with frequencies up to
> 20Ghz), and make the result of the function lose less precision.
>
> Please apply,
>
>
>
> ------------------------------------------------------------------------
>
> --- linux-benh/kernel/cpufreq.c 2002-08-21 17:27:52.000000000 +0200
> +++ linux-yoann/kernel/cpufreq.c 2002-08-22 11:27:09.000000000 +0200
> @@ -78,14 +78,16 @@ static unsigned int cpufreq_
> */
> static unsigned long scale(unsigned long old, u_int div, u_int mult)
> {
> - unsigned long low_part, high_part;
> -
> - high_part = old / div;
> - low_part = (old % div) / 100;
> - high_part *= mult;
> - low_part = low_part * mult / div;
> -
> - return high_part + low_part * 100;
> + unsigned long val, carry = 0;
> +
> + mult /= 100;
> + div /= 100;

if(abs(div)<100) div=0;

> + val = old / div * mult;

Now happily divide by zero.

> +
> + carry = old % div;

Again.

> + carry = carry * mult / div;

Again.

> +
> + return val + carry;
> }
>

And I can't see how it can be more precise, you divide the numerator and
denominator of the fraction by 100 and then proceed forgetting
everything about the rest. Basically this looses about 7 bits of precision.

Now altogether I believe that such a function pertains to a per arch
optimized routine.