David Rientjes <rientjes@xxxxxxxxxx> 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@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. 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@xxxxxxxxxx> -- Greg -- 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>