From patchwork Sat Apr 7 10:38:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tetsuo Handa X-Patchwork-Id: 10327793 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1CF286053F for ; Sat, 7 Apr 2018 10:39:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F2399295FA for ; Sat, 7 Apr 2018 10:39:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E30BE29606; Sat, 7 Apr 2018 10:39:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 05E4E295FA for ; Sat, 7 Apr 2018 10:39:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751367AbeDGKjS (ORCPT ); Sat, 7 Apr 2018 06:39:18 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:47906 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751181AbeDGKjR (ORCPT ); Sat, 7 Apr 2018 06:39:17 -0400 Received: from fsav301.sakura.ne.jp (fsav301.sakura.ne.jp [153.120.85.132]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w37AcSfU010284; Sat, 7 Apr 2018 19:38:28 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav301.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav301.sakura.ne.jp); Sat, 07 Apr 2018 19:38:28 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav301.sakura.ne.jp) Received: from AQUA (softbank126099184120.bbtec.net [126.99.184.120]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w37AcSY7010279; Sat, 7 Apr 2018 19:38:28 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) To: akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, kirill.shutemov@linux.intel.com, mhocko@suse.com, riel@redhat.com Subject: Re: [PATCH] mm: Check for SIGKILL inside dup_mmap() loop. From: Tetsuo Handa References: <1522322870-4335-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <20180329143003.c52ada618be599c5358e8ca2@linux-foundation.org> In-Reply-To: <20180329143003.c52ada618be599c5358e8ca2@linux-foundation.org> Message-Id: <201804071938.CDE04681.SOFVQJFtMHOOLF@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Sat, 7 Apr 2018 19:38:28 +0900 Mime-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP >From 31c863e57a4ab7dfb491b2860fe3653e1e8f593b Mon Sep 17 00:00:00 2001 From: Tetsuo Handa 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 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 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);