On 04/30/2014 12:12 PM, Michal Hocko wrote:
On Wed 30-04-14 12:04:04, Maxim Patlasov wrote:
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():
The bug might trigger even if setpoint < limit because the result is
trucated to s32 and I guess this is what is going on here?
Is (limit - setpoint + 1) > 4G possible?
Yes, you are right. Probably the problem came from s32 overflow.
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 <riel@xxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
---
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>