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@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>