All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suren Baghdasaryan <surenb@google.com>
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
Subject: [PATCH v2 1/3] mm, oom: move task_will_free_mem up in the file to be used in process_mrelease
Date: Sun, 18 Jul 2021 14:41:32 -0700	[thread overview]
Message-ID: <20210718214134.2619099-1-surenb@google.com> (raw)

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 <surenb@google.com>
---
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


             reply	other threads:[~2021-07-18 21:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-18 21:41 Suren Baghdasaryan [this message]
2021-07-18 21:41 ` [PATCH v2 1/3] mm, oom: move task_will_free_mem up in the file to be used in process_mrelease Suren Baghdasaryan
2021-07-18 21:41 ` [PATCH v2 2/3] mm: introduce process_mrelease system call Suren Baghdasaryan
2021-07-18 21:41   ` Suren Baghdasaryan
2021-07-21  8:02   ` David Hildenbrand
2021-07-21 15:43     ` Suren Baghdasaryan
2021-07-21 15:43       ` Suren Baghdasaryan
2021-07-21 22:59       ` Suren Baghdasaryan
2021-07-21 22:59         ` Suren Baghdasaryan
2021-07-22  7:45         ` David Hildenbrand
2021-07-18 21:41 ` [PATCH v2 3/3] mm: wire up syscall process_mrelease Suren Baghdasaryan
2021-07-18 21:41   ` Suren Baghdasaryan
2021-07-20 12:43 ` [PATCH v2 1/3] mm, oom: move task_will_free_mem up in the file to be used in process_mrelease David Hildenbrand
2021-07-20 16:18   ` Suren Baghdasaryan
2021-07-20 16:18     ` Suren Baghdasaryan
2021-07-20 23:07   ` Andrew Morton
2021-07-21  7:30     ` David Hildenbrand
2021-07-21 15:33       ` Suren Baghdasaryan
2021-07-21 15:33         ` Suren Baghdasaryan
2021-07-21 16:12         ` David Hildenbrand
2021-07-21 20:19           ` Suren Baghdasaryan
2021-07-21 20:19             ` Suren Baghdasaryan
2021-07-21 20:50             ` Andrew Morton
2021-07-21 20:59               ` Suren Baghdasaryan
2021-07-21 20:59                 ` Suren Baghdasaryan
2021-07-23  1:15                 ` Suren Baghdasaryan
2021-07-23  1:15                   ` Suren Baghdasaryan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210718214134.2619099-1-surenb@google.com \
    --to=surenb@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=christian@brauner.io \
    --cc=david@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=hch@infradead.org \
    --cc=jannh@google.com \
    --cc=jengelh@inai.de \
    --cc=kernel-team@android.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=oleg@redhat.com \
    --cc=riel@surriel.com \
    --cc=rientjes@google.com \
    --cc=shakeelb@google.com \
    --cc=timmurray@google.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.