From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Tetsuo Handa To: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Cc: Tetsuo Handa , Alexander Viro , Andrew Morton , "Kirill A. Shutemov" , Michal Hocko , Rik van Riel Subject: [PATCH] mm: Check for SIGKILL inside dup_mmap() loop. Date: Thu, 29 Mar 2018 20:27:50 +0900 Message-Id: <1522322870-4335-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> Sender: owner-linux-mm@kvack.org List-ID: Theoretically it is possible that an mm_struct with 60000+ vmas loops with potentially allocating memory, with mm->mmap_sem held for write by the current thread. Unless I overlooked that fatal_signal_pending() is somewhere in the loop, this is bad if current thread was selected as an OOM victim, for the current thread will continue allocations using memory reserves while the OOM reaper is unable to reclaim memory. But there is no point with continuing the loop from the beginning if current thread is killed. If there were __GFP_KILLABLE (or something like memalloc_nofs_save()/memalloc_nofs_restore()), we could apply it to all allocations inside the loop. But since we don't have such flag, this patch uses fatal_signal_pending() check inside the loop. Signed-off-by: Tetsuo Handa Cc: Alexander Viro Cc: Andrew Morton Cc: Rik van Riel Cc: Michal Hocko Cc: Kirill A. Shutemov --- kernel/fork.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/fork.c b/kernel/fork.c index 1e8c9a7..38d5baa 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -440,6 +440,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