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
next reply other threads:[~2021-07-18 21:41 UTC|newest]
Thread overview: 17+ 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 2/3] mm: introduce process_mrelease system call Suren Baghdasaryan
2021-07-21 8:02 ` David Hildenbrand
2021-07-21 15:43 ` 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-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 23:07 ` Andrew Morton
2021-07-21 7:30 ` David Hildenbrand
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:50 ` Andrew Morton
2021-07-21 20:59 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).