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 <[email protected]>
---
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
In modern systems it's not unusual to have a system component monitoring
memory conditions of the system and tasked with keeping system memory
pressure under control. One way to accomplish that is to kill
non-essential processes to free up memory for more important ones.
Examples of this are Facebook's OOM killer daemon called oomd and
Android's low memory killer daemon called lmkd.
For such system component it's important to be able to free memory
quickly and efficiently. Unfortunately the time process takes to free
up its memory after receiving a SIGKILL might vary based on the state
of the process (uninterruptible sleep), size and OPP level of the core
the process is running. A mechanism to free resources of the target
process in a more predictable way would improve system's ability to
control its memory pressure.
Introduce process_mrelease system call that releases memory of a dying
process from the context of the caller. This way the memory is freed in
a more controllable way with CPU affinity and priority of the caller.
The workload of freeing the memory will also be charged to the caller.
The operation is allowed only on a dying process.
Previously I proposed a number of alternatives to accomplish this:
- https://lore.kernel.org/patchwork/patch/1060407 extending
pidfd_send_signal to allow memory reaping using oom_reaper thread;
- https://lore.kernel.org/patchwork/patch/1338196 extending
pidfd_send_signal to reap memory of the target process synchronously from
the context of the caller;
- https://lore.kernel.org/patchwork/patch/1344419/ to add MADV_DONTNEED
support for process_madvise implementing synchronous memory reaping.
The end of the last discussion culminated with suggestion to introduce a
dedicated system call (https://lore.kernel.org/patchwork/patch/1344418/#1553875)
The reasoning was that the new variant of process_madvise
a) does not work on an address range
b) is destructive
c) doesn't share much code at all with the rest of process_madvise
From the userspace point of view it was awkward and inconvenient to provide
memory range for this operation that operates on the entire address space.
Using special flags or address values to specify the entire address space
was too hacky.
The API is as follows,
int process_mrelease(int pidfd, unsigned int flags);
DESCRIPTION
The process_mrelease() system call is used to free the memory of
a process which was sent a SIGKILL signal.
The pidfd selects the process referred to by the PID file
descriptor.
(See pidofd_open(2) for further information)
The flags argument is reserved for future use; currently, this
argument must be specified as 0.
RETURN VALUE
On success, process_mrelease() returns 0. On error, -1 is
returned and errno is set to indicate the error.
ERRORS
EBADF pidfd is not a valid PID file descriptor.
EAGAIN Failed to release part of the address space.
EINVAL flags is not 0.
EINVAL The task does not have a pending SIGKILL or its memory is
shared with another process with no pending SIGKILL.
ENOSYS This system call is not supported by kernels built with no
MMU support (CONFIG_MMU=n).
ESRCH The target process does not exist (i.e., it has terminated
and been waited on).
Signed-off-by: Suren Baghdasaryan <[email protected]>
---
mm/oom_kill.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index d04a13dc9fde..7fbfa70d4e97 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -28,6 +28,7 @@
#include <linux/sched/task.h>
#include <linux/sched/debug.h>
#include <linux/swap.h>
+#include <linux/syscalls.h>
#include <linux/timex.h>
#include <linux/jiffies.h>
#include <linux/cpuset.h>
@@ -755,10 +756,64 @@ static int __init oom_init(void)
return 0;
}
subsys_initcall(oom_init)
+
+SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
+{
+ struct pid *pid;
+ struct task_struct *task;
+ struct mm_struct *mm = NULL;
+ unsigned int f_flags;
+ long ret = 0;
+
+ if (flags != 0)
+ return -EINVAL;
+
+ pid = pidfd_get_pid(pidfd, &f_flags);
+ if (IS_ERR(pid))
+ return PTR_ERR(pid);
+
+ task = get_pid_task(pid, PIDTYPE_PID);
+ if (!task) {
+ ret = -ESRCH;
+ goto put_pid;
+ }
+
+ /*
+ * If the task is dying and in the process of releasing its memory
+ * then get its mm.
+ */
+ task_lock(task);
+ if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
+ mm = task->mm;
+ mmget(mm);
+ }
+ task_unlock(task);
+ if (!mm) {
+ ret = -EINVAL;
+ goto put_task;
+ }
+
+ mmap_read_lock(mm);
+ if (!__oom_reap_task_mm(mm))
+ ret = -EAGAIN;
+ mmap_read_unlock(mm);
+
+ mmput(mm);
+put_task:
+ put_task_struct(task);
+put_pid:
+ put_pid(pid);
+ return ret;
+}
#else
static inline void wake_oom_reaper(struct task_struct *tsk)
{
}
+
+SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
+{
+ return -ENOSYS;
+}
#endif /* CONFIG_MMU */
/**
--
2.32.0.402.g57bb445576-goog
Split off from prev patch in the series that implements the syscall.
Signed-off-by: Suren Baghdasaryan <[email protected]>
---
arch/alpha/kernel/syscalls/syscall.tbl | 2 ++
arch/arm/tools/syscall.tbl | 2 ++
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 ++
arch/ia64/kernel/syscalls/syscall.tbl | 2 ++
arch/m68k/kernel/syscalls/syscall.tbl | 2 ++
arch/microblaze/kernel/syscalls/syscall.tbl | 2 ++
arch/mips/kernel/syscalls/syscall_n32.tbl | 2 ++
arch/mips/kernel/syscalls/syscall_n64.tbl | 2 ++
arch/mips/kernel/syscalls/syscall_o32.tbl | 2 ++
arch/parisc/kernel/syscalls/syscall.tbl | 2 ++
arch/powerpc/kernel/syscalls/syscall.tbl | 2 ++
arch/s390/kernel/syscalls/syscall.tbl | 2 ++
arch/sh/kernel/syscalls/syscall.tbl | 2 ++
arch/sparc/kernel/syscalls/syscall.tbl | 2 ++
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 2 ++
include/linux/syscalls.h | 1 +
include/uapi/asm-generic/unistd.h | 4 +++-
kernel/sys_ni.c | 1 +
21 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl
index a17687ed4b51..605645eae04c 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -486,3 +486,5 @@
554 common landlock_create_ruleset sys_landlock_create_ruleset
555 common landlock_add_rule sys_landlock_add_rule
556 common landlock_restrict_self sys_landlock_restrict_self
+# 557 reserved for memfd_secret
+558 common process_mrelease sys_process_mrelease
diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
index c5df1179fc5d..2f32eb8beca8 100644
--- a/arch/arm/tools/syscall.tbl
+++ b/arch/arm/tools/syscall.tbl
@@ -460,3 +460,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index 727bfc3be99b..3cb206aea3db 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -38,7 +38,7 @@
#define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE + 5)
#define __ARM_NR_COMPAT_END (__ARM_NR_COMPAT_BASE + 0x800)
-#define __NR_compat_syscalls 447
+#define __NR_compat_syscalls 449
#endif
#define __ARCH_WANT_SYS_CLONE
diff --git a/arch/arm64/include/asm/unistd32.h b/arch/arm64/include/asm/unistd32.h
index 99ffcafc736c..0f49cdb180dd 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -901,6 +901,8 @@ __SYSCALL(__NR_landlock_create_ruleset, sys_landlock_create_ruleset)
__SYSCALL(__NR_landlock_add_rule, sys_landlock_add_rule)
#define __NR_landlock_restrict_self 446
__SYSCALL(__NR_landlock_restrict_self, sys_landlock_restrict_self)
+#define __NR_process_mrelease 448
+__SYSCALL(__NR_process_mrelease, sys_process_mrelease)
/*
* Please add new compat syscalls above this comment and update
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl b/arch/ia64/kernel/syscalls/syscall.tbl
index 6d07742c57b8..9bf45f2be966 100644
--- a/arch/ia64/kernel/syscalls/syscall.tbl
+++ b/arch/ia64/kernel/syscalls/syscall.tbl
@@ -367,3 +367,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease
diff --git a/arch/m68k/kernel/syscalls/syscall.tbl b/arch/m68k/kernel/syscalls/syscall.tbl
index 541bc1b3a8f9..f1f98ee6c82d 100644
--- a/arch/m68k/kernel/syscalls/syscall.tbl
+++ b/arch/m68k/kernel/syscalls/syscall.tbl
@@ -446,3 +446,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease
diff --git a/arch/microblaze/kernel/syscalls/syscall.tbl b/arch/microblaze/kernel/syscalls/syscall.tbl
index a176faca2927..da49ddd4bb54 100644
--- a/arch/microblaze/kernel/syscalls/syscall.tbl
+++ b/arch/microblaze/kernel/syscalls/syscall.tbl
@@ -452,3 +452,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease
diff --git a/arch/mips/kernel/syscalls/syscall_n32.tbl b/arch/mips/kernel/syscalls/syscall_n32.tbl
index c2d2e19abea8..56c8d3cf42ed 100644
--- a/arch/mips/kernel/syscalls/syscall_n32.tbl
+++ b/arch/mips/kernel/syscalls/syscall_n32.tbl
@@ -385,3 +385,5 @@
444 n32 landlock_create_ruleset sys_landlock_create_ruleset
445 n32 landlock_add_rule sys_landlock_add_rule
446 n32 landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 n32 process_mrelease sys_process_mrelease
diff --git a/arch/mips/kernel/syscalls/syscall_n64.tbl b/arch/mips/kernel/syscalls/syscall_n64.tbl
index ac653d08b1ea..1ca7bc337932 100644
--- a/arch/mips/kernel/syscalls/syscall_n64.tbl
+++ b/arch/mips/kernel/syscalls/syscall_n64.tbl
@@ -361,3 +361,5 @@
444 n64 landlock_create_ruleset sys_landlock_create_ruleset
445 n64 landlock_add_rule sys_landlock_add_rule
446 n64 landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 n64 process_mrelease sys_process_mrelease
diff --git a/arch/mips/kernel/syscalls/syscall_o32.tbl b/arch/mips/kernel/syscalls/syscall_o32.tbl
index 253f2cd70b6b..fd3a9df60ec2 100644
--- a/arch/mips/kernel/syscalls/syscall_o32.tbl
+++ b/arch/mips/kernel/syscalls/syscall_o32.tbl
@@ -434,3 +434,5 @@
444 o32 landlock_create_ruleset sys_landlock_create_ruleset
445 o32 landlock_add_rule sys_landlock_add_rule
446 o32 landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 o32 process_mrelease sys_process_mrelease
diff --git a/arch/parisc/kernel/syscalls/syscall.tbl b/arch/parisc/kernel/syscalls/syscall.tbl
index e26187b9ab87..040df1b7a589 100644
--- a/arch/parisc/kernel/syscalls/syscall.tbl
+++ b/arch/parisc/kernel/syscalls/syscall.tbl
@@ -444,3 +444,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease
diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
index aef2a290e71a..d8ebd7d37c0f 100644
--- a/arch/powerpc/kernel/syscalls/syscall.tbl
+++ b/arch/powerpc/kernel/syscalls/syscall.tbl
@@ -526,3 +526,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease
diff --git a/arch/s390/kernel/syscalls/syscall.tbl b/arch/s390/kernel/syscalls/syscall.tbl
index 64d51ab5a8b4..57233ace30cb 100644
--- a/arch/s390/kernel/syscalls/syscall.tbl
+++ b/arch/s390/kernel/syscalls/syscall.tbl
@@ -449,3 +449,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease sys_process_mrelease
diff --git a/arch/sh/kernel/syscalls/syscall.tbl b/arch/sh/kernel/syscalls/syscall.tbl
index e0a70be77d84..2f6e95eb4690 100644
--- a/arch/sh/kernel/syscalls/syscall.tbl
+++ b/arch/sh/kernel/syscalls/syscall.tbl
@@ -449,3 +449,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease
diff --git a/arch/sparc/kernel/syscalls/syscall.tbl b/arch/sparc/kernel/syscalls/syscall.tbl
index 603f5a821502..42fc2906215d 100644
--- a/arch/sparc/kernel/syscalls/syscall.tbl
+++ b/arch/sparc/kernel/syscalls/syscall.tbl
@@ -492,3 +492,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease
diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
index ce763a12311c..661a03bcfbd1 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -452,3 +452,4 @@
445 i386 landlock_add_rule sys_landlock_add_rule
446 i386 landlock_restrict_self sys_landlock_restrict_self
447 i386 memfd_secret sys_memfd_secret
+448 i386 process_mrelease sys_process_mrelease
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
index f6b57799c1ea..807b6a1de8e8 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -369,6 +369,7 @@
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
447 common memfd_secret sys_memfd_secret
+448 common process_mrelease sys_process_mrelease
#
# Due to a historical design error, certain syscalls are numbered differently
diff --git a/arch/xtensa/kernel/syscalls/syscall.tbl b/arch/xtensa/kernel/syscalls/syscall.tbl
index 235d67d6ceb4..f4384951f393 100644
--- a/arch/xtensa/kernel/syscalls/syscall.tbl
+++ b/arch/xtensa/kernel/syscalls/syscall.tbl
@@ -417,3 +417,5 @@
444 common landlock_create_ruleset sys_landlock_create_ruleset
445 common landlock_add_rule sys_landlock_add_rule
446 common landlock_restrict_self sys_landlock_restrict_self
+# 447 reserved for memfd_secret
+448 common process_mrelease sys_process_mrelease
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 69c9a7010081..00bc170a50f0 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -915,6 +915,7 @@ asmlinkage long sys_mincore(unsigned long start, size_t len,
asmlinkage long sys_madvise(unsigned long start, size_t len, int behavior);
asmlinkage long sys_process_madvise(int pidfd, const struct iovec __user *vec,
size_t vlen, int behavior, unsigned int flags);
+asmlinkage long sys_process_mrelease(int pidfd, unsigned int flags);
asmlinkage long sys_remap_file_pages(unsigned long start, unsigned long size,
unsigned long prot, unsigned long pgoff,
unsigned long flags);
diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
index a9d6fcd95f42..14c8fe863c6d 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -877,9 +877,11 @@ __SYSCALL(__NR_landlock_restrict_self, sys_landlock_restrict_self)
#define __NR_memfd_secret 447
__SYSCALL(__NR_memfd_secret, sys_memfd_secret)
#endif
+#define __NR_process_mrelease 448
+__SYSCALL(__NR_process_mrelease, sys_process_mrelease)
#undef __NR_syscalls
-#define __NR_syscalls 448
+#define __NR_syscalls 449
/*
* 32 bit systems traditionally used different
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 30971b1dd4a9..18a9c2cde767 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -289,6 +289,7 @@ COND_SYSCALL(munlockall);
COND_SYSCALL(mincore);
COND_SYSCALL(madvise);
COND_SYSCALL(process_madvise);
+COND_SYSCALL(process_mrelease);
COND_SYSCALL(remap_file_pages);
COND_SYSCALL(mbind);
COND_SYSCALL_COMPAT(mbind);
--
2.32.0.402.g57bb445576-goog
On 18.07.21 23:41, Suren Baghdasaryan wrote:
> 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 <[email protected]>
> ---
> 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(-)
TBH, I really dislike this move as it makes git blame a lot harder with
any real benefit.
Can't you just use prototypes to avoid the move for now in patch #2?
static bool task_will_free_mem(struct task_struct *task);
--
Thanks,
David / dhildenb
On Tue, Jul 20, 2021 at 5:44 AM David Hildenbrand <[email protected]> wrote:
>
> On 18.07.21 23:41, Suren Baghdasaryan wrote:
> > 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 <[email protected]>
> > ---
> > 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(-)
>
> TBH, I really dislike this move as it makes git blame a lot harder with
> any real benefit.
>
> Can't you just use prototypes to avoid the move for now in patch #2?
>
> static bool task_will_free_mem(struct task_struct *task);
Sure, I can use a forward-declaration. Just thought this would be
cleaner. Will change in the next rev. Thanks!
>
>
> --
> Thanks,
>
> David / dhildenb
>
On Tue, 20 Jul 2021 14:43:52 +0200 David Hildenbrand <[email protected]> wrote:
> On 18.07.21 23:41, Suren Baghdasaryan wrote:
> > 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 <[email protected]>
> > ---
> > 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(-)
>
> TBH, I really dislike this move as it makes git blame a lot harder with
> any real benefit.
>
> Can't you just use prototypes to avoid the move for now in patch #2?
>
> static bool task_will_free_mem(struct task_struct *task);
This change makes the code better - it's silly to be adding forward
declarations just because the functions are in the wrong place.
If that messes up git-blame then let's come up with better tooling
rather than suffering poorer kernel code because the tools aren't doing
what we want of them. Surely?
On 21.07.21 01:07, Andrew Morton wrote:
> On Tue, 20 Jul 2021 14:43:52 +0200 David Hildenbrand <[email protected]> wrote:
>
>> On 18.07.21 23:41, Suren Baghdasaryan wrote:
>>> 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 <[email protected]>
>>> ---
>>> 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(-)
>>
>> TBH, I really dislike this move as it makes git blame a lot harder with
>> any real benefit.
>>
>> Can't you just use prototypes to avoid the move for now in patch #2?
>>
>> static bool task_will_free_mem(struct task_struct *task);
>
> This change makes the code better - it's silly to be adding forward
> declarations just because the functions are in the wrong place.
I'd really love to learn what "better" here means and if it's rather
subjective. When it comes to navigating the code, we do have established
tools for that (ctags), and personally I couldn't care less where
exactly in a file the code is located.
Sure, ending up with a forward-declaration for every function might not
be what we want ;)
>
> If that messes up git-blame then let's come up with better tooling
> rather than suffering poorer kernel code because the tools aren't doing
> what we want of them. Surely?
I don't agree that what we get is "poorer kernel code" in this very
instance; I can understand that we avoid forward-declarations when
moving smallish functions. But moving two functions with 75 LOC is a bit
too much for my taste at least -- speaking as someone who cares about
easy backports and git-blame.
Anyhow, just my 2 cents.
--
Thanks,
David / dhildenb
On 18.07.21 23:41, Suren Baghdasaryan wrote:
> In modern systems it's not unusual to have a system component monitoring
> memory conditions of the system and tasked with keeping system memory
> pressure under control. One way to accomplish that is to kill
> non-essential processes to free up memory for more important ones.
> Examples of this are Facebook's OOM killer daemon called oomd and
> Android's low memory killer daemon called lmkd.
> For such system component it's important to be able to free memory
> quickly and efficiently. Unfortunately the time process takes to free
> up its memory after receiving a SIGKILL might vary based on the state
> of the process (uninterruptible sleep), size and OPP level of the core
> the process is running. A mechanism to free resources of the target
> process in a more predictable way would improve system's ability to
> control its memory pressure.
> Introduce process_mrelease system call that releases memory of a dying
> process from the context of the caller. This way the memory is freed in
> a more controllable way with CPU affinity and priority of the caller.
> The workload of freeing the memory will also be charged to the caller.
> The operation is allowed only on a dying process.
>
> Previously I proposed a number of alternatives to accomplish this:
> - https://lore.kernel.org/patchwork/patch/1060407 extending
> pidfd_send_signal to allow memory reaping using oom_reaper thread;
> - https://lore.kernel.org/patchwork/patch/1338196 extending
> pidfd_send_signal to reap memory of the target process synchronously from
> the context of the caller;
> - https://lore.kernel.org/patchwork/patch/1344419/ to add MADV_DONTNEED
> support for process_madvise implementing synchronous memory reaping.
To me, this looks a lot cleaner. Although I do wonder why we need two
separate mechanisms to achieve the end goal
1. send sigkill
2. process_mrelease
As 2. doesn't make sense without 1. it somehow feels like it would be
optimal to achieve both steps in a single syscall. But I remember there
were discussions around that.
>
> The end of the last discussion culminated with suggestion to introduce a
> dedicated system call (https://lore.kernel.org/patchwork/patch/1344418/#1553875)
> The reasoning was that the new variant of process_madvise
> a) does not work on an address range
> b) is destructive
> c) doesn't share much code at all with the rest of process_madvise
> From the userspace point of view it was awkward and inconvenient to provide
> memory range for this operation that operates on the entire address space.
> Using special flags or address values to specify the entire address space
> was too hacky.
>
> The API is as follows,
>
> int process_mrelease(int pidfd, unsigned int flags);
>
> DESCRIPTION
> The process_mrelease() system call is used to free the memory of
> a process which was sent a SIGKILL signal.
>
> The pidfd selects the process referred to by the PID file
> descriptor.
> (See pidofd_open(2) for further information)
>
> The flags argument is reserved for future use; currently, this
> argument must be specified as 0.
>
> RETURN VALUE
> On success, process_mrelease() returns 0. On error, -1 is
> returned and errno is set to indicate the error.
>
> ERRORS
> EBADF pidfd is not a valid PID file descriptor.
>
> EAGAIN Failed to release part of the address space.
>
> EINVAL flags is not 0.
>
> EINVAL The task does not have a pending SIGKILL or its memory is
> shared with another process with no pending SIGKILL.
>
> ENOSYS This system call is not supported by kernels built with no
> MMU support (CONFIG_MMU=n).
>
> ESRCH The target process does not exist (i.e., it has terminated
> and been waited on).
>
> Signed-off-by: Suren Baghdasaryan <[email protected]>
> ---
> mm/oom_kill.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index d04a13dc9fde..7fbfa70d4e97 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -28,6 +28,7 @@
> #include <linux/sched/task.h>
> #include <linux/sched/debug.h>
> #include <linux/swap.h>
> +#include <linux/syscalls.h>
> #include <linux/timex.h>
> #include <linux/jiffies.h>
> #include <linux/cpuset.h>
> @@ -755,10 +756,64 @@ static int __init oom_init(void)
> return 0;
> }
> subsys_initcall(oom_init)
> +
> +SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
> +{
> + struct pid *pid;
> + struct task_struct *task;
> + struct mm_struct *mm = NULL;
> + unsigned int f_flags;
> + long ret = 0;
Nit: reverse Christmas tree.
> +
> + if (flags != 0)
> + return -EINVAL;
> +
> + pid = pidfd_get_pid(pidfd, &f_flags);
> + if (IS_ERR(pid))
> + return PTR_ERR(pid);
> +
> + task = get_pid_task(pid, PIDTYPE_PID);
> + if (!task) {
> + ret = -ESRCH;
> + goto put_pid;
> + }
> +
> + /*
> + * If the task is dying and in the process of releasing its memory
> + * then get its mm.
> + */
> + task_lock(task);
> + if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
> + mm = task->mm;
> + mmget(mm);
> + }
AFAIU, while holding the task_lock, task->mm won't change and we cannot
see a concurrent exit_mm()->mmput(). So the mm structure and the VMAs
won't go away while holding the task_lock(). I do wonder if we need the
mmget() at all here.
Also, I wonder if it would be worth dropping the task_lock() while
reaping - to unblock anybody else wanting to lock the task. Getting a
hold of the mm and locking the mmap_lock would be sufficient I guess.
In general, looks quite good to me.
--
Thanks,
David / dhildenb
On Wed, Jul 21, 2021 at 9:13 AM David Hildenbrand <[email protected]> wrote:
>
> On 21.07.21 17:33, Suren Baghdasaryan wrote:
> > On Wed, Jul 21, 2021 at 12:30 AM David Hildenbrand <[email protected]> wrote:
> >>
> >> On 21.07.21 01:07, Andrew Morton wrote:
> >>> On Tue, 20 Jul 2021 14:43:52 +0200 David Hildenbrand <[email protected]> wrote:
> >>>
> >>>> On 18.07.21 23:41, Suren Baghdasaryan wrote:
> >>>>> 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 <[email protected]>
> >>>>> ---
> >>>>> 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(-)
> >>>>
> >>>> TBH, I really dislike this move as it makes git blame a lot harder with
> >>>> any real benefit.
> >>>>
> >>>> Can't you just use prototypes to avoid the move for now in patch #2?
> >>>>
> >>>> static bool task_will_free_mem(struct task_struct *task);
> >>>
> >>> This change makes the code better - it's silly to be adding forward
> >>> declarations just because the functions are in the wrong place.
> >>
> >> I'd really love to learn what "better" here means and if it's rather
> >> subjective. When it comes to navigating the code, we do have established
> >> tools for that (ctags), and personally I couldn't care less where
> >> exactly in a file the code is located.
> >>
> >> Sure, ending up with a forward-declaration for every function might not
> >> be what we want ;)
> >>
> >>>
> >>> If that messes up git-blame then let's come up with better tooling
> >>> rather than suffering poorer kernel code because the tools aren't doing
> >>> what we want of them. Surely?
> >>
> >> I don't agree that what we get is "poorer kernel code" in this very
> >> instance; I can understand that we avoid forward-declarations when
> >> moving smallish functions. But moving two functions with 75 LOC is a bit
> >> too much for my taste at least -- speaking as someone who cares about
> >> easy backports and git-blame.
> >
> > There is a third alternative here to have process_mrelease() at the
> > end of the file with its own #ifdef CONFIG_MMU block, maybe even
> > embedded in the function like this:
> >
> > int process_mrelease(int pidfd, unsigned int flags)
> > {
> > #ifdef CONFIG_MMU
> > ...
> > #else
> > return ENOSYS;
> > #endif
> > }
> >
> > This would not require moving other functions.
> > Would that be better than the current approach or the forward declaration?
>
> IMHO that could be an easy, possible alternative.
Andrew, others? Should I follow this path instead?
>
> --
> Thanks,
>
> David / dhildenb
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
>
On Wed, 21 Jul 2021 13:19:35 -0700 Suren Baghdasaryan <[email protected]> wrote:
> > > This would not require moving other functions.
> > > Would that be better than the current approach or the forward declaration?
> >
> > IMHO that could be an easy, possible alternative.
>
> Andrew, others? Should I follow this path instead?
Whatever you prefer ;)
On Wed, Jul 21, 2021 at 1:02 AM David Hildenbrand <[email protected]> wrote:
>
> On 18.07.21 23:41, Suren Baghdasaryan wrote:
> > In modern systems it's not unusual to have a system component monitoring
> > memory conditions of the system and tasked with keeping system memory
> > pressure under control. One way to accomplish that is to kill
> > non-essential processes to free up memory for more important ones.
> > Examples of this are Facebook's OOM killer daemon called oomd and
> > Android's low memory killer daemon called lmkd.
> > For such system component it's important to be able to free memory
> > quickly and efficiently. Unfortunately the time process takes to free
> > up its memory after receiving a SIGKILL might vary based on the state
> > of the process (uninterruptible sleep), size and OPP level of the core
> > the process is running. A mechanism to free resources of the target
> > process in a more predictable way would improve system's ability to
> > control its memory pressure.
> > Introduce process_mrelease system call that releases memory of a dying
> > process from the context of the caller. This way the memory is freed in
> > a more controllable way with CPU affinity and priority of the caller.
> > The workload of freeing the memory will also be charged to the caller.
> > The operation is allowed only on a dying process.
> >
> > Previously I proposed a number of alternatives to accomplish this:
> > - https://lore.kernel.org/patchwork/patch/1060407 extending
> > pidfd_send_signal to allow memory reaping using oom_reaper thread;
> > - https://lore.kernel.org/patchwork/patch/1338196 extending
> > pidfd_send_signal to reap memory of the target process synchronously from
> > the context of the caller;
> > - https://lore.kernel.org/patchwork/patch/1344419/ to add MADV_DONTNEED
> > support for process_madvise implementing synchronous memory reaping.
>
> To me, this looks a lot cleaner. Although I do wonder why we need two
> separate mechanisms to achieve the end goal
>
> 1. send sigkill
> 2. process_mrelease
>
> As 2. doesn't make sense without 1. it somehow feels like it would be
> optimal to achieve both steps in a single syscall. But I remember there
> were discussions around that.
Yep, we recently discussed the approach in this thread:
https://lore.kernel.org/patchwork/patch/1450952/#1652452
>
> >
> > The end of the last discussion culminated with suggestion to introduce a
> > dedicated system call (https://lore.kernel.org/patchwork/patch/1344418/#1553875)
> > The reasoning was that the new variant of process_madvise
> > a) does not work on an address range
> > b) is destructive
> > c) doesn't share much code at all with the rest of process_madvise
> > From the userspace point of view it was awkward and inconvenient to provide
> > memory range for this operation that operates on the entire address space.
> > Using special flags or address values to specify the entire address space
> > was too hacky.
> >
> > The API is as follows,
> >
> > int process_mrelease(int pidfd, unsigned int flags);
> >
> > DESCRIPTION
> > The process_mrelease() system call is used to free the memory of
> > a process which was sent a SIGKILL signal.
> >
> > The pidfd selects the process referred to by the PID file
> > descriptor.
> > (See pidofd_open(2) for further information)
> >
> > The flags argument is reserved for future use; currently, this
> > argument must be specified as 0.
> >
> > RETURN VALUE
> > On success, process_mrelease() returns 0. On error, -1 is
> > returned and errno is set to indicate the error.
> >
> > ERRORS
> > EBADF pidfd is not a valid PID file descriptor.
> >
> > EAGAIN Failed to release part of the address space.
> >
> > EINVAL flags is not 0.
> >
> > EINVAL The task does not have a pending SIGKILL or its memory is
> > shared with another process with no pending SIGKILL.
> >
> > ENOSYS This system call is not supported by kernels built with no
> > MMU support (CONFIG_MMU=n).
> >
> > ESRCH The target process does not exist (i.e., it has terminated
> > and been waited on).
> >
> > Signed-off-by: Suren Baghdasaryan <[email protected]>
> > ---
> > mm/oom_kill.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 55 insertions(+)
> >
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index d04a13dc9fde..7fbfa70d4e97 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -28,6 +28,7 @@
> > #include <linux/sched/task.h>
> > #include <linux/sched/debug.h>
> > #include <linux/swap.h>
> > +#include <linux/syscalls.h>
> > #include <linux/timex.h>
> > #include <linux/jiffies.h>
> > #include <linux/cpuset.h>
> > @@ -755,10 +756,64 @@ static int __init oom_init(void)
> > return 0;
> > }
> > subsys_initcall(oom_init)
> > +
> > +SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
> > +{
> > + struct pid *pid;
> > + struct task_struct *task;
> > + struct mm_struct *mm = NULL;
> > + unsigned int f_flags;
> > + long ret = 0;
>
> Nit: reverse Christmas tree.
Ack. Will reorder like this:
struct mm_struct *mm = NULL;
struct task_struct *task;
unsigned int f_flags;
struct pid *pid;
long ret = 0;
>
> > +
> > + if (flags != 0)
> > + return -EINVAL;
> > +
> > + pid = pidfd_get_pid(pidfd, &f_flags);
> > + if (IS_ERR(pid))
> > + return PTR_ERR(pid);
> > +
> > + task = get_pid_task(pid, PIDTYPE_PID);
> > + if (!task) {
> > + ret = -ESRCH;
> > + goto put_pid;
> > + }
> > +
> > + /*
> > + * If the task is dying and in the process of releasing its memory
> > + * then get its mm.
> > + */
> > + task_lock(task);
> > + if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
> > + mm = task->mm;
> > + mmget(mm);
> > + }
>
> AFAIU, while holding the task_lock, task->mm won't change and we cannot
> see a concurrent exit_mm()->mmput(). So the mm structure and the VMAs
> won't go away while holding the task_lock(). I do wonder if we need the
> mmget() at all here.
>
> Also, I wonder if it would be worth dropping the task_lock() while
> reaping - to unblock anybody else wanting to lock the task. Getting a
> hold of the mm and locking the mmap_lock would be sufficient I guess.
Let me take a closer look at the locking sequence here and will follow
up afterwards.
Thanks for the review!
>
>
> In general, looks quite good to me.
>
> --
> Thanks,
>
> David / dhildenb
>
On Wed, Jul 21, 2021 at 12:30 AM David Hildenbrand <[email protected]> wrote:
>
> On 21.07.21 01:07, Andrew Morton wrote:
> > On Tue, 20 Jul 2021 14:43:52 +0200 David Hildenbrand <[email protected]> wrote:
> >
> >> On 18.07.21 23:41, Suren Baghdasaryan wrote:
> >>> 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 <[email protected]>
> >>> ---
> >>> 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(-)
> >>
> >> TBH, I really dislike this move as it makes git blame a lot harder with
> >> any real benefit.
> >>
> >> Can't you just use prototypes to avoid the move for now in patch #2?
> >>
> >> static bool task_will_free_mem(struct task_struct *task);
> >
> > This change makes the code better - it's silly to be adding forward
> > declarations just because the functions are in the wrong place.
>
> I'd really love to learn what "better" here means and if it's rather
> subjective. When it comes to navigating the code, we do have established
> tools for that (ctags), and personally I couldn't care less where
> exactly in a file the code is located.
>
> Sure, ending up with a forward-declaration for every function might not
> be what we want ;)
>
> >
> > If that messes up git-blame then let's come up with better tooling
> > rather than suffering poorer kernel code because the tools aren't doing
> > what we want of them. Surely?
>
> I don't agree that what we get is "poorer kernel code" in this very
> instance; I can understand that we avoid forward-declarations when
> moving smallish functions. But moving two functions with 75 LOC is a bit
> too much for my taste at least -- speaking as someone who cares about
> easy backports and git-blame.
There is a third alternative here to have process_mrelease() at the
end of the file with its own #ifdef CONFIG_MMU block, maybe even
embedded in the function like this:
int process_mrelease(int pidfd, unsigned int flags)
{
#ifdef CONFIG_MMU
...
#else
return ENOSYS;
#endif
}
This would not require moving other functions.
Would that be better than the current approach or the forward declaration?
>
> Anyhow, just my 2 cents.
>
> --
> Thanks,
>
> David / dhildenb
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
>
On 21.07.21 17:33, Suren Baghdasaryan wrote:
> On Wed, Jul 21, 2021 at 12:30 AM David Hildenbrand <[email protected]> wrote:
>>
>> On 21.07.21 01:07, Andrew Morton wrote:
>>> On Tue, 20 Jul 2021 14:43:52 +0200 David Hildenbrand <[email protected]> wrote:
>>>
>>>> On 18.07.21 23:41, Suren Baghdasaryan wrote:
>>>>> 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 <[email protected]>
>>>>> ---
>>>>> 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(-)
>>>>
>>>> TBH, I really dislike this move as it makes git blame a lot harder with
>>>> any real benefit.
>>>>
>>>> Can't you just use prototypes to avoid the move for now in patch #2?
>>>>
>>>> static bool task_will_free_mem(struct task_struct *task);
>>>
>>> This change makes the code better - it's silly to be adding forward
>>> declarations just because the functions are in the wrong place.
>>
>> I'd really love to learn what "better" here means and if it's rather
>> subjective. When it comes to navigating the code, we do have established
>> tools for that (ctags), and personally I couldn't care less where
>> exactly in a file the code is located.
>>
>> Sure, ending up with a forward-declaration for every function might not
>> be what we want ;)
>>
>>>
>>> If that messes up git-blame then let's come up with better tooling
>>> rather than suffering poorer kernel code because the tools aren't doing
>>> what we want of them. Surely?
>>
>> I don't agree that what we get is "poorer kernel code" in this very
>> instance; I can understand that we avoid forward-declarations when
>> moving smallish functions. But moving two functions with 75 LOC is a bit
>> too much for my taste at least -- speaking as someone who cares about
>> easy backports and git-blame.
>
> There is a third alternative here to have process_mrelease() at the
> end of the file with its own #ifdef CONFIG_MMU block, maybe even
> embedded in the function like this:
>
> int process_mrelease(int pidfd, unsigned int flags)
> {
> #ifdef CONFIG_MMU
> ...
> #else
> return ENOSYS;
> #endif
> }
>
> This would not require moving other functions.
> Would that be better than the current approach or the forward declaration?
IMHO that could be an easy, possible alternative.
--
Thanks,
David / dhildenb
On Wed, Jul 21, 2021 at 1:51 PM Andrew Morton <[email protected]> wrote:
>
> On Wed, 21 Jul 2021 13:19:35 -0700 Suren Baghdasaryan <[email protected]> wrote:
>
> > > > This would not require moving other functions.
> > > > Would that be better than the current approach or the forward declaration?
> > >
> > > IMHO that could be an easy, possible alternative.
> >
> > Andrew, others? Should I follow this path instead?
>
> Whatever you prefer ;)
I understand David's concern too well to ignore it, so I prefer to
follow this middle-ground approach if you don't mind :)
On Wed, Jul 21, 2021 at 8:43 AM Suren Baghdasaryan <[email protected]> wrote:
>
> On Wed, Jul 21, 2021 at 1:02 AM David Hildenbrand <[email protected]> wrote:
> >
> > On 18.07.21 23:41, Suren Baghdasaryan wrote:
> > > In modern systems it's not unusual to have a system component monitoring
> > > memory conditions of the system and tasked with keeping system memory
> > > pressure under control. One way to accomplish that is to kill
> > > non-essential processes to free up memory for more important ones.
> > > Examples of this are Facebook's OOM killer daemon called oomd and
> > > Android's low memory killer daemon called lmkd.
> > > For such system component it's important to be able to free memory
> > > quickly and efficiently. Unfortunately the time process takes to free
> > > up its memory after receiving a SIGKILL might vary based on the state
> > > of the process (uninterruptible sleep), size and OPP level of the core
> > > the process is running. A mechanism to free resources of the target
> > > process in a more predictable way would improve system's ability to
> > > control its memory pressure.
> > > Introduce process_mrelease system call that releases memory of a dying
> > > process from the context of the caller. This way the memory is freed in
> > > a more controllable way with CPU affinity and priority of the caller.
> > > The workload of freeing the memory will also be charged to the caller.
> > > The operation is allowed only on a dying process.
> > >
> > > Previously I proposed a number of alternatives to accomplish this:
> > > - https://lore.kernel.org/patchwork/patch/1060407 extending
> > > pidfd_send_signal to allow memory reaping using oom_reaper thread;
> > > - https://lore.kernel.org/patchwork/patch/1338196 extending
> > > pidfd_send_signal to reap memory of the target process synchronously from
> > > the context of the caller;
> > > - https://lore.kernel.org/patchwork/patch/1344419/ to add MADV_DONTNEED
> > > support for process_madvise implementing synchronous memory reaping.
> >
> > To me, this looks a lot cleaner. Although I do wonder why we need two
> > separate mechanisms to achieve the end goal
> >
> > 1. send sigkill
> > 2. process_mrelease
> >
> > As 2. doesn't make sense without 1. it somehow feels like it would be
> > optimal to achieve both steps in a single syscall. But I remember there
> > were discussions around that.
>
> Yep, we recently discussed the approach in this thread:
> https://lore.kernel.org/patchwork/patch/1450952/#1652452
>
> >
> > >
> > > The end of the last discussion culminated with suggestion to introduce a
> > > dedicated system call (https://lore.kernel.org/patchwork/patch/1344418/#1553875)
> > > The reasoning was that the new variant of process_madvise
> > > a) does not work on an address range
> > > b) is destructive
> > > c) doesn't share much code at all with the rest of process_madvise
> > > From the userspace point of view it was awkward and inconvenient to provide
> > > memory range for this operation that operates on the entire address space.
> > > Using special flags or address values to specify the entire address space
> > > was too hacky.
> > >
> > > The API is as follows,
> > >
> > > int process_mrelease(int pidfd, unsigned int flags);
> > >
> > > DESCRIPTION
> > > The process_mrelease() system call is used to free the memory of
> > > a process which was sent a SIGKILL signal.
> > >
> > > The pidfd selects the process referred to by the PID file
> > > descriptor.
> > > (See pidofd_open(2) for further information)
> > >
> > > The flags argument is reserved for future use; currently, this
> > > argument must be specified as 0.
> > >
> > > RETURN VALUE
> > > On success, process_mrelease() returns 0. On error, -1 is
> > > returned and errno is set to indicate the error.
> > >
> > > ERRORS
> > > EBADF pidfd is not a valid PID file descriptor.
> > >
> > > EAGAIN Failed to release part of the address space.
> > >
> > > EINVAL flags is not 0.
> > >
> > > EINVAL The task does not have a pending SIGKILL or its memory is
> > > shared with another process with no pending SIGKILL.
> > >
> > > ENOSYS This system call is not supported by kernels built with no
> > > MMU support (CONFIG_MMU=n).
> > >
> > > ESRCH The target process does not exist (i.e., it has terminated
> > > and been waited on).
> > >
> > > Signed-off-by: Suren Baghdasaryan <[email protected]>
> > > ---
> > > mm/oom_kill.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 55 insertions(+)
> > >
> > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > > index d04a13dc9fde..7fbfa70d4e97 100644
> > > --- a/mm/oom_kill.c
> > > +++ b/mm/oom_kill.c
> > > @@ -28,6 +28,7 @@
> > > #include <linux/sched/task.h>
> > > #include <linux/sched/debug.h>
> > > #include <linux/swap.h>
> > > +#include <linux/syscalls.h>
> > > #include <linux/timex.h>
> > > #include <linux/jiffies.h>
> > > #include <linux/cpuset.h>
> > > @@ -755,10 +756,64 @@ static int __init oom_init(void)
> > > return 0;
> > > }
> > > subsys_initcall(oom_init)
> > > +
> > > +SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
> > > +{
> > > + struct pid *pid;
> > > + struct task_struct *task;
> > > + struct mm_struct *mm = NULL;
> > > + unsigned int f_flags;
> > > + long ret = 0;
> >
> > Nit: reverse Christmas tree.
>
> Ack. Will reorder like this:
>
> struct mm_struct *mm = NULL;
> struct task_struct *task;
> unsigned int f_flags;
> struct pid *pid;
> long ret = 0;
>
> >
> > > +
> > > + if (flags != 0)
> > > + return -EINVAL;
> > > +
> > > + pid = pidfd_get_pid(pidfd, &f_flags);
> > > + if (IS_ERR(pid))
> > > + return PTR_ERR(pid);
> > > +
> > > + task = get_pid_task(pid, PIDTYPE_PID);
> > > + if (!task) {
> > > + ret = -ESRCH;
> > > + goto put_pid;
> > > + }
> > > +
> > > + /*
> > > + * If the task is dying and in the process of releasing its memory
> > > + * then get its mm.
> > > + */
> > > + task_lock(task);
> > > + if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
> > > + mm = task->mm;
> > > + mmget(mm);
> > > + }
> >
> > AFAIU, while holding the task_lock, task->mm won't change and we cannot
> > see a concurrent exit_mm()->mmput(). So the mm structure and the VMAs
> > won't go away while holding the task_lock(). I do wonder if we need the
> > mmget() at all here.
We do mmget() here to ensure mm is stable when it is passed later to
__oom_reap_task_mm(mm)/mmap_read_lock(mm)/mmap_read_unlock(mm). Note
that during those calls we do not hold task_lock anymore.
> >
> > Also, I wonder if it would be worth dropping the task_lock() while
> > reaping - to unblock anybody else wanting to lock the task.
As I mentioned above, we do not hold task_lock during reaping. We
release it right after we call task_will_free_mem(), which checks that
the task is exiting. task_lock is held during the call to
task_will_free_mem() to satisfy the requirement listed in that
function's comment: "Caller has to make sure that task->mm is stable
(hold task_lock or it operates on the current)".
> > Getting a hold of the mm and locking the mmap_lock would be sufficient I guess.
That's exactly what I do here. The simplified sequence is:
task_lock
if (task_will_free_mem())
mm=mmget()
task_unlock
if (!mm) return;
mmap_read_lock(mm)
__oom_reap_task_mm(mm)
mmap_read_unlock(mm)
mmput(mm)
Or did I misunderstand your comments?
>
> Let me take a closer look at the locking sequence here and will follow
> up afterwards.
> Thanks for the review!
>
> >
> >
> > In general, looks quite good to me.
> >
> > --
> > Thanks,
> >
> > David / dhildenb
> >
>>> Getting a hold of the mm and locking the mmap_lock would be sufficient I guess.
>
> That's exactly what I do here. The simplified sequence is:
>
> task_lock
> if (task_will_free_mem())
> mm=mmget()
> task_unlock
> if (!mm) return;
>
> mmap_read_lock(mm)
> __oom_reap_task_mm(mm)
> mmap_read_unlock(mm)
> mmput(mm)
>
> Or did I misunderstand your comments?
Oh, sorry, my tired eyes confused "put_task_struct()" with
"task_unlock()" and even "mmget()" with "mmgrab()" ...
So this is essentially get_task_mm() with an additional
task_will_free_mem() check.
LGHTM!
:)
--
Thanks,
David / dhildenb
On Wed, Jul 21, 2021 at 1:59 PM Suren Baghdasaryan <[email protected]> wrote:
>
> On Wed, Jul 21, 2021 at 1:51 PM Andrew Morton <[email protected]> wrote:
> >
> > On Wed, 21 Jul 2021 13:19:35 -0700 Suren Baghdasaryan <[email protected]> wrote:
> >
> > > > > This would not require moving other functions.
> > > > > Would that be better than the current approach or the forward declaration?
> > > >
> > > > IMHO that could be an easy, possible alternative.
> > >
> > > Andrew, others? Should I follow this path instead?
> >
> > Whatever you prefer ;)
>
> I understand David's concern too well to ignore it, so I prefer to
> follow this middle-ground approach if you don't mind :)
v3 with the refactoring is posted at
https://lore.kernel.org/patchwork/project/lkml/list/?series=509230