lkml.org 
[lkml]   [2014]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3] mm,writeback: fix divide by zero in pos_ratio_polynom
On 04/30/2014 03:00 PM, Andrew Morton wrote:
> On Wed, 30 Apr 2014 10:41:14 -0400 Rik van Riel <riel@redhat.com> wrote:
>
>> It is possible for "limit - setpoint + 1" to equal zero, leading to a
>> divide by zero error. Blindly adding 1 to "limit - setpoint" is not
>> working, so we need to actually test the divisor before calling div64.
>>
>> ...
>>
>> --- a/mm/page-writeback.c
>> +++ b/mm/page-writeback.c
>> @@ -598,10 +598,15 @@ static inline long long pos_ratio_polynom(unsigned long setpoint,
>> unsigned long limit)
>> {
>> long long pos_ratio;
>> + long divisor;
>> long x;
>>
>> + divisor = limit - setpoint;
>> + if (!(s32)divisor)
>> + divisor = 1; /* Avoid div-by-zero */
>> +
>> x = div_s64(((s64)setpoint - (s64)dirty) << RATELIMIT_CALC_SHIFT,
>> - limit - setpoint + 1);
>> + (s32)divisor);
>
> Doesn't this just paper over the bug one time in four billion? The
> other 3999999999 times, pos_ratio_polynom() returns an incorect result?
>
> If it is indeed the case that pos_ratio_polynom() callers are
> legitimately passing a setpoint which is more than 2^32 less than limit
> then it would be better to handle that input correctly.

The easy way would be by calling div64_s64 and div64_u64,
which are 64 bit all the way through.

Any objections?

The inlined bits seem to be stubs calling the _rem variants
of the functions, and discarding the remainder.



\
 
 \ /
  Last update: 2014-04-30 22:01    [W:0.054 / U:1.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site