]> 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>
Mon, 19 Dec 2011 07:19:52 +0000 (18:19 +1100)
commit3a4f6d282bfbf3de09620ee2a754d20f24fba225
tree7b3141406ae5e60eeeeca7777bd5e30dfb1b9622
parent46766aa1f5509683ec8acdc7486935873f1e810c
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