]> git.karo-electronics.de Git - karo-tx-linux.git/commit
oom, memcg: fix exclusion of memcg threads after they have detached their mm
authorDavid Rientjes <rientjes@google.com>
Fri, 16 Dec 2011 04:50:39 +0000 (15:50 +1100)
committerStephen Rothwell <sfr@canb.auug.org.au>
Wed, 21 Dec 2011 06:02:00 +0000 (17:02 +1100)
commit1f49e4c674292b8dd2b2ce4ccb706767a35ccbb6
tree2464988f3ef3b4cc1d712c972beae7be79277edf
parent245048e87ccf54db28307eff7e4c51d98bcbe00e
oom, memcg: fix exclusion of memcg threads after they have detached their mm

The oom killer relies on logic that identifies threads that have already
been oom killed when scanning the tasklist and, if found, deferring until
such threads have exited.  This is done by checking for any candidate
threads that have the TIF_MEMDIE bit set.

For memcg ooms, candidate threads are first found by calling
task_in_mem_cgroup() since the oom killer should not defer if there's an
oom killed thread in another memcg.

Unfortunately, task_in_mem_cgroup() excludes threads if they have detached
their mm in the process of exiting so TIF_MEMDIE is never detected for
such conditions.  This is different for global, mempolicy, and cpuset oom
conditions where a detached mm is only excluded after checking for
TIF_MEMDIE and deferring, if necessary, in select_bad_process().

The fix is to return true if a task has a detached mm but is still in the
memcg or its hierarchy that is currently oom.  This will allow the oom
killer to appropriately defer rather than kill unnecessarily or, in the
worst case, panic the machine if nothing else is available to kill.

Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/memcontrol.c