* [patch -mm] oom: avoid divide by zero
@ 2010-04-27 23:01 David Rientjes
2010-04-28 0:56 ` KAMEZAWA Hiroyuki
2010-04-28 6:26 ` Greg Thelen
0 siblings, 2 replies; 3+ messages in thread
From: David Rientjes @ 2010-04-27 23:01 UTC (permalink / raw)
To: Andrew Morton
Cc: KAMEZAWA Hiroyuki, KOSAKI Motohiro, Balbir Singh, Greg Thelen, linux-mm
It's evidently possible for a memory controller to have a limit of 0
bytes, so it's possible for the oom killer to have a divide by zero error
in such circumstances.
When this is the case, each candidate task's rss and swap is divided by
one so they are essentially ranked according to whichever task attached
to the cgroup has the most resident RAM and swap.
Reported-by: Greg Thelen <gthelen@google.com>
Signed-off-by: David Rientjes <rientjes@google.com>
---
mm/oom_kill.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -189,6 +189,14 @@ unsigned int oom_badness(struct task_struct *p, unsigned long totalpages)
p = find_lock_task_mm(p);
if (!p)
return 0;
+
+ /*
+ * The memory controller can have a limit of 0 bytes, so avoid a divide
+ * by zero if necessary.
+ */
+ if (!totalpages)
+ totalpages = 1;
+
/*
* The baseline for the badness score is the proportion of RAM that each
* task's rss and swap space use.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch -mm] oom: avoid divide by zero
2010-04-27 23:01 [patch -mm] oom: avoid divide by zero David Rientjes
@ 2010-04-28 0:56 ` KAMEZAWA Hiroyuki
2010-04-28 6:26 ` Greg Thelen
1 sibling, 0 replies; 3+ messages in thread
From: KAMEZAWA Hiroyuki @ 2010-04-28 0:56 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, KOSAKI Motohiro, Balbir Singh, Greg Thelen, linux-mm
On Tue, 27 Apr 2010 16:01:00 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:
> It's evidently possible for a memory controller to have a limit of 0
> bytes, so it's possible for the oom killer to have a divide by zero error
> in such circumstances.
>
> When this is the case, each candidate task's rss and swap is divided by
> one so they are essentially ranked according to whichever task attached
> to the cgroup has the most resident RAM and swap.
>
> Reported-by: Greg Thelen <gthelen@google.com>
> Signed-off-by: David Rientjes <rientjes@google.com>
Oh, thank you !
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> mm/oom_kill.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -189,6 +189,14 @@ unsigned int oom_badness(struct task_struct *p, unsigned long totalpages)
> p = find_lock_task_mm(p);
> if (!p)
> return 0;
> +
> + /*
> + * The memory controller can have a limit of 0 bytes, so avoid a divide
> + * by zero if necessary.
> + */
> + if (!totalpages)
> + totalpages = 1;
> +
> /*
> * The baseline for the badness score is the proportion of RAM that each
> * task's rss and swap space use.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch -mm] oom: avoid divide by zero
2010-04-27 23:01 [patch -mm] oom: avoid divide by zero David Rientjes
2010-04-28 0:56 ` KAMEZAWA Hiroyuki
@ 2010-04-28 6:26 ` Greg Thelen
1 sibling, 0 replies; 3+ messages in thread
From: Greg Thelen @ 2010-04-28 6:26 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, KAMEZAWA Hiroyuki, KOSAKI Motohiro, Balbir Singh,
linux-mm
David Rientjes <rientjes@google.com> writes:
> It's evidently possible for a memory controller to have a limit of 0
> bytes, so it's possible for the oom killer to have a divide by zero error
> in such circumstances.
>
> When this is the case, each candidate task's rss and swap is divided by
> one so they are essentially ranked according to whichever task attached
> to the cgroup has the most resident RAM and swap.
>
> Reported-by: Greg Thelen <gthelen@google.com>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
> mm/oom_kill.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -189,6 +189,14 @@ unsigned int oom_badness(struct task_struct *p, unsigned long totalpages)
> p = find_lock_task_mm(p);
> if (!p)
> return 0;
> +
> + /*
> + * The memory controller can have a limit of 0 bytes, so avoid a divide
> + * by zero if necessary.
> + */
> + if (!totalpages)
> + totalpages = 1;
> +
> /*
> * The baseline for the badness score is the proportion of RAM that each
> * task's rss and swap space use.
I tested 2.6.34-rc5 + mmotm-2010-04-22-16-38 and the provided patch
fixes the reported problem.
Thanks David.
Tested-by: Greg Thelen <gthelen@google.com>
--
Greg
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-04-28 6:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-27 23:01 [patch -mm] oom: avoid divide by zero David Rientjes
2010-04-28 0:56 ` KAMEZAWA Hiroyuki
2010-04-28 6:26 ` Greg Thelen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox