CHROMIUM: BACKPORT: mm: better fix for OOM killer hang

CHROMIUM: BACKPORT: mm: better fix for OOM killer hang

This change replaces a previous fix for crosbug.com/32321
(https://gerrit.chromium.org/gerrit/#/c/36953) with a better
fix which David Rentjes applies upstream (this is the equivalent
change).  I have studied and tested David's change and it also
avoids the deadlock.  In addition, our change has the potential
for unnecessarily killing processes that don't need to be killed.
Furthermore, it's probably better to track upstream more closely.

 commit 9ff4868e3051d9128a24dd330bed32011a11421d
 Author:     David Rientjes <rientjes@google.com>
 AuthorDate: Tue Dec 11 16:01:30 2012 -0800
 Commit:     Linus Torvalds <torvalds@linux-foundation.org>
 CommitDate: Tue Dec 11 17:22:24 2012 -0800

    mm, oom: allow exiting threads to have access to memory reserves

    Exiting threads, those with PF_EXITING set, can pagefault and require
    memory before they can make forward progress.  This happens, for instance,
    when a process must fault task->robust_list, a userspace structure, before
    detaching its memory.

    These threads also aren't guaranteed to get access to memory reserves
    unless oom killed or killed from userspace.  The oom killer won't grant
    memory reserves if other threads are also exiting other than current and
    stalling at the same point.  This prevents needlessly killing processes
    when others are already exiting.

    Instead of special casing all the possible situations between PF_EXITING
    getting set and a thread detaching its mm where it may allocate memory,
    which probably wouldn't get updated when a change is made to the exit
    path, the solution is to give all exiting threads access to memory
    reserves if they call the oom killer.  This allows them to quickly
    allocate, detach its mm, and free the memory it represents.

    Summary of Luigi's bug report:

    : He had an oom condition where threads were faulting on task->robust_list
    : and repeatedly called the oom killer but it would defer killing a thread
    : because it saw other PF_EXITING threads.  This can happen anytime we need
    : to allocate memory after setting PF_EXITING and before detaching our mm;
    : if there are other threads in the same state then the oom killer won't do
    : anything unless one of them happens to be killed from userspace.
    :
    : So instead of only deferring for PF_EXITING and !task->robust_list, it's
    : better to just give them access to memory reserves to prevent a potential
    : livelock so that any other faults that may be introduced in the future in
    : the exit path don't cause the same problem (and hopefully we don't allow
    : too many of those!).

    Signed-off-by: David Rientjes <rientjes@google.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Tested-by: Luigi Semenzato <semenzato@google.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
BUG=chromium-os:38812
TEST=manually tested in a deadlock situation

Change-Id: If0c52a7009dbc7002d4b26ffe91a1a97989f2215
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39199