Re: [PATCH 07/10] mm, oom: fortify task_will_free_mem
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: 2016-06-09 13:18:36
Also in:
lkml
Michal Hocko wrote:
quoted hunk ↗ jump to hunk
@@ -766,15 +797,12 @@ void oom_kill_process(struct oom_control *oc, struct task_struct *p, * If the task is already exiting, don't alarm the sysadmin or kill * its children or threads, just set TIF_MEMDIE so it can die quickly */ - task_lock(p); - if (p->mm && task_will_free_mem(p)) { + if (task_will_free_mem(p)) {
I think it is possible that p->mm becomes NULL here. Also, I think setting TIF_MEMDIE on p when find_lock_task_mm(p) != p is wrong. While oom_reap_task() will anyway clear TIF_MEMDIE even if we set TIF_MEMDIE on p when p->mm == NULL, it is not true for CONFIG_MMU=n case.
quoted hunk ↗ jump to hunk
mark_oom_victim(p); - try_oom_reaper(p); - task_unlock(p); + wake_oom_reaper(p); put_task_struct(p); return; } - task_unlock(p); if (__ratelimit(&oom_rs)) dump_header(oc, p);@@ -940,14 +968,10 @@ bool out_of_memory(struct oom_control *oc) * If current has a pending SIGKILL or is exiting, then automatically * select it. The goal is to allow it to allocate so that it may * quickly exit and free its memory. - * - * But don't select if current has already released its mm and cleared - * TIF_MEMDIE flag at exit_mm(), otherwise an OOM livelock may occur. */ - if (current->mm && - (fatal_signal_pending(current) || task_will_free_mem(current))) { + if (task_will_free_mem(current)) {
Setting TIF_MEMDIE on current when current->mm == NULL and find_lock_task_mm(current) != NULL is wrong.
mark_oom_victim(current); - try_oom_reaper(current); + wake_oom_reaper(current); return true; }
-- 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>