Hi Rik!
On 04/29/2014 11:19 PM, Rik van Riel 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.
The patch looks correct, but I'm afraid it can hide an actual bug in a
caller of pos_ratio_polynom(). The latter is not intended for setpoint >
limit. All callers take pains to ensure that setpoint <= limit. Look,
for example, at global_dirty_limits():
> if (background >= dirty)
> background = dirty / 2;
If you ever encountered "limit - setpoint + 1" equal zero, it may be
worthy to investigate how you came to setpoint greater than limit.
Thanks,
Maxim
Signed-off-by: Rik van Riel <r...@redhat.com>
Cc: sta...@vger.kernel.org
---
mm/page-writeback.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index ef41349..2682516 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -597,11 +597,16 @@ static inline long long pos_ratio_polynom(unsigned long
setpoint,
unsigned long dirty,
unsigned long limit)
{
+ unsigned int divisor;
long long pos_ratio;
long x;
+ divisor = limit - setpoint;
+ if (!divisor)
+ divisor = 1;
+
x = div_s64(((s64)setpoint - (s64)dirty) << RATELIMIT_CALC_SHIFT,
- limit - setpoint + 1);
+ divisor);
pos_ratio = x;
pos_ratio = pos_ratio * x >> RATELIMIT_CALC_SHIFT;
pos_ratio = pos_ratio * x >> RATELIMIT_CALC_SHIFT;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
