Re: [BUGFIX][PATCH] memcg: fix oom killer kills a task in other cgroup

[David Rientjes <rientjes@google.com>]

On Tue, 9 Feb 2010, Minchan Kim wrote:

> My point was following as.
> We try to kill child of OOMed task at first.
> But we can't know any locked state of child when OOM happens.

We don't need to, child->alloc_lock can be contended in which case we'll 
just spin but it won't stay locked because we're out of memory.  In other 
words, nothing takes task_lock(child) and then waits for memory to become 
available while holding it, that would be fundamentally broken.  So there 
is a dependency here and that is that task_lock(current) can't be taken in 
the page allocator because we'll deadlock in the oom killer, but that 
isn't anything new.

> It means at this point child is able to be holding any lock.
> So if we can try to hold task_lock of child, it could make new lock
> dependency between task_lock and other locks.
> 

The children aren't any special class of processes in this case, we always 
take task_lock() for them during the tasklist scan.  In fact, we can take 
task_lock(p) for the same process p three times during the course of an 
oom kill: once to dump its statistics when /proc/pid/oom_dump_tasks is 
enabled, once to calculate its badness() score, and once to kill it.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>