On 04/30/2014 03:00 PM, Andrew Morton wrote:
On Wed, 30 Apr 2014 10:41:14 -0400 Rik van Riel <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
