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-detaching-mm-prior-to-exit.patch > 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. -- 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>