> On Mon, 29 Mar 2010, anfei wrote:
>
> > I think this method is okay, but it's easy to trigger another bug of
> > oom. See select_bad_process():
> > if (!p->mm)
> > continue;
> > !p->mm is not always an unaccepted condition. e.g. "p" is killed and
> > doing exit, setting tsk->mm to NULL is before releasing the memory.
> > And in multi threading environment, this happens much more.
> > In __out_of_memory(), it panics if select_bad_process returns NULL.
> > The simple way to fix it is as mem_cgroup_out_of_memory() does.
> >
>
> This is fixed by
> oom-avoid-race-for-oom-killed-tasks-detaching-mm-prior-to-exit.patch in
> the -mm tree.
>
> See
>
http://userweb.kernel.org/~akpm/mmotm/broken-out/oom-avoid-race-for-oom-killed-tasks-d...
>
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index afeab2a..9aae208 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -588,12 +588,8 @@ retry:
> > if (PTR_ERR(p) == -1UL)
> > return;
> >
> > - /* Found nothing?!?! Either we hang forever, or we panic. */
> > - if (!p) {
> > - read_unlock(&tasklist_lock);
> > - dump_header(NULL, gfp_mask, order, NULL);
> > - panic("Out of memory and no killable processes...\n");
> > - }
> > + if (!p)
> > + p = current;
> >
> > if (oom_kill_process(p, gfp_mask, order, points, NULL,
> > "Out of memory"))
>
> The reason p wasn't selected is because it fails to meet the criteria for
> candidacy in select_bad_process(), not necessarily because of a race with
> the !p->mm check that the -mm patch cited above fixes. It's quite
> possible that current has an oom_adj value of OOM_DISABLE, for example,
> where this would be wrong.
