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@xxxxxxxxxx> Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx> --- 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@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>