Re: [PATCH] mm,oom_reaper: don't call mmput_async() without atomic_inc_not_zero()
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2016-06-01 22:53:15
On Sat, 28 May 2016 17:16:05 +0900 Tetsuo Handa [off-list ref] wrote:
Commit e2fe14564d3316d1 ("oom_reaper: close race with exiting task")
reduced frequency of needlessly selecting next OOM victim, but was
calling mmput_async() when atomic_inc_not_zero() failed.Changelog fail.
quoted hunk ↗ jump to hunk
--- a/mm/oom_kill.c +++ b/mm/oom_kill.c@@ -478,6 +478,7 @@ static bool __oom_reap_task(struct task_struct *tsk) mm = p->mm; if (!atomic_inc_not_zero(&mm->mm_users)) { task_unlock(p); + mm = NULL; goto unlock_oom; }
This looks like a pretty fatal bug. I assume the result of hitting that race will be a kernel crash, yes? Is it even possible to hit that race? find_lock_task_mm() takes some care to prevent a NULL ->mm. But I guess a concurrent mmput() doesn't require task_lock(). Kinda makes me wonder what's the point in even having find_lock_task_mm() if its guarantee on ->mm is useless... -- 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>