From patchwork Thu Mar 29 11:27:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tetsuo Handa X-Patchwork-Id: 10315059 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 88EEB6055B for ; Thu, 29 Mar 2018 11:29:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 853D92A289 for ; Thu, 29 Mar 2018 11:29:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 788512A2DD; Thu, 29 Mar 2018 11:29:30 +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=-6.9 required=2.0 tests=BAYES_00,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 60FEA2A289 for ; Thu, 29 Mar 2018 11:29:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752854AbeC2L30 (ORCPT ); Thu, 29 Mar 2018 07:29:26 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:20785 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752484AbeC2L3X (ORCPT ); Thu, 29 Mar 2018 07:29:23 -0400 Received: from fsav403.sakura.ne.jp (fsav403.sakura.ne.jp [133.242.250.102]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w2TBRx9M073102; Thu, 29 Mar 2018 20:27:59 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav403.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav403.sakura.ne.jp); Thu, 29 Mar 2018 20:27:59 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav403.sakura.ne.jp) Received: from ccsecurity.localdomain (softbank126099184120.bbtec.net [126.99.184.120]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w2TBRsdB073085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Mar 2018 20:27:59 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) 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> X-Mailer: git-send-email 1.8.3.1 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 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);