Patch "mm, oom: fortify task_will_free_mem" removed p->mm != NULL test for
shortcut path in oom_kill_process(). But since commit f44666b04605d1c7
("mm,oom: speed up select_bad_process() loop") changed to iterate using
thread group leaders, the possibility of p->mm == NULL has increased
compared to when commit 83363b917a2982dd ("oom: make sure that TIF_MEMDIE
is set under task_lock") was proposed. On CONFIG_MMU=n kernels, nothing
will clear TIF_MEMDIE and the system can OOM livelock if TIF_MEMDIE was
by error set to a mm-less thread group leader.
Let's redo find_task_lock_mm() test after task_will_free_mem() returned
true.
Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Oleg Nesterov <oleg@xxxxxxxxxx>
Cc: Vladimir Davydov <vdavydov@xxxxxxxxxxxxx>
Cc: David Rientjes <rientjes@xxxxxxxxxx>
---
mm/oom_kill.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 4c21f74..846d5a7 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -839,9 +839,13 @@ void oom_kill_process(struct oom_control *oc, struct task_struct *p,
* its children or threads, just set TIF_MEMDIE so it can die quickly
*/
if (task_will_free_mem(p)) {
- mark_oom_victim(p);
- wake_oom_reaper(p);
- put_task_struct(p);
+ p = find_lock_task_mm(p);
+ if (p) {
+ mark_oom_victim(p);
+ task_unlock(p);
+ wake_oom_reaper(p);
+ }
+ put_task_struct(victim);
return;
}
--
1.8.3.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>