>From 31c863e57a4ab7dfb491b2860fe3653e1e8f593b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 7 Apr 2018 19:29:30 +0900
Subject: [PATCH] mm: Check for SIGKILL inside dup_mmap() loop.
As a theoretical problem, an mm_struct with 60000+ vmas can loop with
potentially allocating memory, with mm->mmap_sem held for write by current
thread. This is bad if current thread was selected as an OOM victim, for
current thread will continue allocations using memory reserves while OOM
reaper is unable to reclaim memory.
As an actually observable problem, it is not difficult to make OOM reaper
unable to reclaim memory if the OOM victim is blocked at
i_mmap_lock_write() in this loop. Unfortunately, since nobody can explain
whether it is safe to use killable wait there, let's check for SIGKILL
before trying to allocate memory. Even without an OOM event, there is no
point with continuing the loop from the beginning if current thread is
killed.
Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Cc: Rik van Riel <riel@xxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
---
kernel/fork.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index 242c8c9..8831bae 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -441,6 +441,10 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
continue;
}
charge = 0;
+ if (fatal_signal_pending(current)) {
+ retval = -EINTR;
+ goto out;
+ }
if (mpnt->vm_flags & VM_ACCOUNT) {
unsigned long len = vma_pages(mpnt);
--
1.8.3.1
