Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3203294pxv; Sun, 18 Jul 2021 14:43:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznNVrJxHtBv1TlLS0caf/V7W5tV6JKQ7EkrOG5ZS+WJOAIJrotBjOWgaTrUyucsBCDnYN4 X-Received: by 2002:a17:906:31cb:: with SMTP id f11mr24636872ejf.379.1626644582236; Sun, 18 Jul 2021 14:43:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626644582; cv=none; d=google.com; s=arc-20160816; b=jHwOPr2EBU9OfpW8pTI2xKlPh9BVIgElIhlKv27puJn7v3EBL6cWcYootBappB1kyk FAPpc+RUGhjtf/wnhBABQN1mPn2WgRGa1sCfMKjtRbeq44hEkfTnEJGysp/0b6dWnDhC A2hKio2hWsTaJXK4HjmPQCIPkR1qfmMc6a4VLF7ZpjNrutAUBelsYBB5nEA0UkQwlnz9 +vSUafJNuoVe2xNwXnt4U/xQhSwyK+gTSKI3MRoJ+2eqqIUvEUGO/gzT1WOrAX+uxi1e yn0GRDZt5o9LLu9Wx1AJkhSZmywx13Xpo5jVqAkcF98JL6GOqDrIRBMLT7WWYCj0YeQP kCxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id:date :dkim-signature; bh=34U0ArTGqmXEjhOeCq4v/OslLn/g3DytngGhTp5TZL8=; b=oPKRumjKQvUehG/lYmpU2EOmxGlxuRzBbCS82aZ+x0ZlUnl0/cc3qiB/rojJy2ClMo G1GHLyM9KKTeqk/WOockMxzt/AszQxUqv30EWd4y6hmCqoaBuJgb1uw59UkECCB2Zkfx T0nuFQVUbJXQuCMXdw6uyHzTr9R8GlU3NFtHTa9EzNTtp9sSyZMBUCCQa2Cd/zbqtPzU fRme9+8wmYC4zsLgbaQPsIKcnyA6x42ZiK0Y3UFCNyeOvLkN4jWtC9MPkUyXX4mfkabc 0UmM5azLoDUCj88JmMT6AhAu7Ps/NKyxbacTFXlXZePWXj5jmPvyQ6OfoDrd/qL1S5ps +E/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="pPvAdUp/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h8si8042051ede.86.2021.07.18.14.42.39; Sun, 18 Jul 2021 14:43:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="pPvAdUp/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229585AbhGRVoj (ORCPT + 99 others); Sun, 18 Jul 2021 17:44:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229853AbhGRVoi (ORCPT ); Sun, 18 Jul 2021 17:44:38 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60FAAC061762 for ; Sun, 18 Jul 2021 14:41:40 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id s186-20020a252cc30000b029055bc7fcfebdso22364140ybs.12 for ; Sun, 18 Jul 2021 14:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=34U0ArTGqmXEjhOeCq4v/OslLn/g3DytngGhTp5TZL8=; b=pPvAdUp/CHeFKkyssuk3noamEwEUQ430z6Mm20okH/S7xjTEMSN1hLsGZyoIoqrNNS rzGK9ki2izgz4kD3nHi/YreNd4EAvRfyoeihoKKXGV7J+C6YcJIS0zn9s5tqxBNvPGIP CoYhAbkMOQE1fN18Jgyf8pF55oBU0iJdtTVwskGFybU3brpP1tWl6JZDfuFbbm1Zf3c2 J5jfRBIUo+KEkQ9aUIW16s+J/v1hZDIVunR0lwrOIrhIONqBXZ2t7yGWPA+OOrSgaP5o lCR1vkyk7/alS9/emKMVqI9iNUS3KzrGBXzEwgzgeThZ7sKMYsQVxgkWSifn3LDH6kxd m3ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=34U0ArTGqmXEjhOeCq4v/OslLn/g3DytngGhTp5TZL8=; b=DelLeqNA5MnuLE6UimrofdE1HRVXG82YLQepS1MO6Ap9rEoL+68Gg1VjG+w+NccyTU S+vECmgNAK14+Opk7WI74/IcUIWS9ZF3yDUQwcCSmWQ6dQ9aj5Qq5ytI+uF/GTPkIO8z A33MJ7DfmUqyhGTAGoFOngyFeMlD7aPY6sxKnVwPfn4Q1+Jl/PYU615+VuJRb53Dsf2a uP/XnnD2wNKXcKlc6Gs6D8djvSNvompty5BEhZSQ89qM81g6tbMASIvFKz7Q4A4az6zS 3Zkp1vZ8u8ylKGW7EIMtaLmSEkpE7ZGFzOX3GSQcHNYL3h08x140BROzJ0k1fke0R8sX VE2A== X-Gm-Message-State: AOAM531eASR8eAEICug+qta9em5d8eah9l9bhVlewaWDRDy1Vfla4cTO Cbw+BSHEv+dT306/i7Wn5HiMAp3MvrI= X-Received: from surenb1.mtv.corp.google.com ([2620:15c:211:200:b347:cf97:e43a:9891]) (user=surenb job=sendgmr) by 2002:a25:694f:: with SMTP id e76mr26374379ybc.119.1626644498976; Sun, 18 Jul 2021 14:41:38 -0700 (PDT) Date: Sun, 18 Jul 2021 14:41:32 -0700 Message-Id: <20210718214134.2619099-1-surenb@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.32.0.402.g57bb445576-goog Subject: [PATCH v2 1/3] mm, oom: move task_will_free_mem up in the file to be used in process_mrelease From: Suren Baghdasaryan To: akpm@linux-foundation.org Cc: mhocko@kernel.org, mhocko@suse.com, rientjes@google.com, willy@infradead.org, hannes@cmpxchg.org, guro@fb.com, riel@surriel.com, minchan@kernel.org, christian@brauner.io, hch@infradead.org, oleg@redhat.com, david@redhat.com, jannh@google.com, shakeelb@google.com, luto@kernel.org, christian.brauner@ubuntu.com, fweimer@redhat.com, jengelh@inai.de, timmurray@google.com, linux-api@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com, surenb@google.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org process_mrelease needs to be added in the CONFIG_MMU-dependent block which comes before __task_will_free_mem and task_will_free_mem. Move these functions before this block so that new process_mrelease syscall can use them. Signed-off-by: Suren Baghdasaryan --- changes in v2: - Fixed build error when CONFIG_MMU=n, reported by kernel test robot. This required moving task_will_free_mem implemented in the first patch - Renamed process_reap to process_mrelease, per majority of votes - Replaced "dying process" with "process which was sent a SIGKILL signal" in the manual page text, per Florian Weimer - Added ERRORS section in the manual page text - Resolved conflicts in syscall numbers caused by the new memfd_secret syscall - Separated boilerplate code wiring-up the new syscall into a separate patch to facilitate the review process mm/oom_kill.c | 150 +++++++++++++++++++++++++------------------------- 1 file changed, 75 insertions(+), 75 deletions(-) diff --git a/mm/oom_kill.c b/mm/oom_kill.c index c729a4c4a1ac..d04a13dc9fde 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -501,6 +501,81 @@ bool process_shares_mm(struct task_struct *p, struct mm_struct *mm) return false; } +static inline bool __task_will_free_mem(struct task_struct *task) +{ + struct signal_struct *sig = task->signal; + + /* + * A coredumping process may sleep for an extended period in exit_mm(), + * so the oom killer cannot assume that the process will promptly exit + * and release memory. + */ + if (sig->flags & SIGNAL_GROUP_COREDUMP) + return false; + + if (sig->flags & SIGNAL_GROUP_EXIT) + return true; + + if (thread_group_empty(task) && (task->flags & PF_EXITING)) + return true; + + return false; +} + +/* + * Checks whether the given task is dying or exiting and likely to + * release its address space. This means that all threads and processes + * sharing the same mm have to be killed or exiting. + * Caller has to make sure that task->mm is stable (hold task_lock or + * it operates on the current). + */ +static bool task_will_free_mem(struct task_struct *task) +{ + struct mm_struct *mm = task->mm; + struct task_struct *p; + bool ret = true; + + /* + * Skip tasks without mm because it might have passed its exit_mm and + * exit_oom_victim. oom_reaper could have rescued that but do not rely + * on that for now. We can consider find_lock_task_mm in future. + */ + if (!mm) + return false; + + if (!__task_will_free_mem(task)) + return false; + + /* + * This task has already been drained by the oom reaper so there are + * only small chances it will free some more + */ + if (test_bit(MMF_OOM_SKIP, &mm->flags)) + return false; + + if (atomic_read(&mm->mm_users) <= 1) + return true; + + /* + * Make sure that all tasks which share the mm with the given tasks + * are dying as well to make sure that a) nobody pins its mm and + * b) the task is also reapable by the oom reaper. + */ + rcu_read_lock(); + for_each_process(p) { + if (!process_shares_mm(p, mm)) + continue; + if (same_thread_group(task, p)) + continue; + ret = __task_will_free_mem(p); + if (!ret) + break; + } + rcu_read_unlock(); + + return ret; +} + #ifdef CONFIG_MMU /* * OOM Reaper kernel thread which tries to reap the memory used by the OOM @@ -781,81 +856,6 @@ bool oom_killer_disable(signed long timeout) return true; } -static inline bool __task_will_free_mem(struct task_struct *task) -{ - struct signal_struct *sig = task->signal; - - /* - * A coredumping process may sleep for an extended period in exit_mm(), - * so the oom killer cannot assume that the process will promptly exit - * and release memory. - */ - if (sig->flags & SIGNAL_GROUP_COREDUMP) - return false; - - if (sig->flags & SIGNAL_GROUP_EXIT) - return true; - - if (thread_group_empty(task) && (task->flags & PF_EXITING)) - return true; - - return false; -} - -/* - * Checks whether the given task is dying or exiting and likely to - * release its address space. This means that all threads and processes - * sharing the same mm have to be killed or exiting. - * Caller has to make sure that task->mm is stable (hold task_lock or - * it operates on the current). - */ -static bool task_will_free_mem(struct task_struct *task) -{ - struct mm_struct *mm = task->mm; - struct task_struct *p; - bool ret = true; - - /* - * Skip tasks without mm because it might have passed its exit_mm and - * exit_oom_victim. oom_reaper could have rescued that but do not rely - * on that for now. We can consider find_lock_task_mm in future. - */ - if (!mm) - return false; - - if (!__task_will_free_mem(task)) - return false; - - /* - * This task has already been drained by the oom reaper so there are - * only small chances it will free some more - */ - if (test_bit(MMF_OOM_SKIP, &mm->flags)) - return false; - - if (atomic_read(&mm->mm_users) <= 1) - return true; - - /* - * Make sure that all tasks which share the mm with the given tasks - * are dying as well to make sure that a) nobody pins its mm and - * b) the task is also reapable by the oom reaper. - */ - rcu_read_lock(); - for_each_process(p) { - if (!process_shares_mm(p, mm)) - continue; - if (same_thread_group(task, p)) - continue; - ret = __task_will_free_mem(p); - if (!ret) - break; - } - rcu_read_unlock(); - - return ret; -} - static void __oom_kill_process(struct task_struct *victim, const char *message) { struct task_struct *p; -- 2.32.0.402.g57bb445576-goog