[PATCH v4 1/2] mm: introduce process_mrelease system call

Subsystems: memory management, memory management - oom killer, the rest

STALE1899d

9 messages, 3 authors, 2021-08-04 · open the first message on its own page

[PATCH v4 1/2] mm: introduce process_mrelease system call

From: Suren Baghdasaryan <surenb@google.com>
Date: 2021-08-02 22:14:44

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.

          EINTR  The call was interrupted by a signal; see signal(7).

          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 <surenb@google.com>
---
changes in v4:
- Replaced mmap_read_lock() with mmap_read_lock_killable(), per Michal Hocko
- Added EINTR error in the manual pages documentation

 mm/oom_kill.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index c729a4c4a1ac..86727794b0a8 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>
@@ -1141,3 +1142,60 @@ void pagefault_out_of_memory(void)
 	out_of_memory(&oc);
 	mutex_unlock(&oom_lock);
 }
+
+SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
+{
+#ifdef CONFIG_MMU
+	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);
+	}
+	task_unlock(task);
+	if (!mm) {
+		ret = -EINVAL;
+		goto put_task;
+	}
+
+	if (mmap_read_lock_killable(mm)) {
+		ret = -EINTR;
+		goto put_mm;
+	}
+	if (!__oom_reap_task_mm(mm))
+		ret = -EAGAIN;
+	mmap_read_unlock(mm);
+
+put_mm:
+	mmput(mm);
+put_task:
+	put_task_struct(task);
+put_pid:
+	put_pid(pid);
+	return ret;
+#else
+	return -ENOSYS;
+#endif /* CONFIG_MMU */
+}
-- 
2.32.0.554.ge1b32706d8-goog

[PATCH v4 2/2] mm: wire up syscall process_mrelease

From: Suren Baghdasaryan <surenb@google.com>
Date: 2021-08-02 22:14:46

Split off from prev patch in the series that implements the syscall.

Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
 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.554.ge1b32706d8-goog

Re: [PATCH v4 1/2] mm: introduce process_mrelease system call

From: David Hildenbrand <hidden>
Date: 2021-08-03 07:48:29

[...]
Previously I proposed a number of alternatives to accomplish this:
- https://lore.kernel.org/patchwork/patch/1060407 extending
I have no idea how stable these links are. Referencing via message id is the common practice. For this link, we'd use

https://lkml.kernel.org/r/20190411014353.113252-3-surenb@google.com/

instead.
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.
I'd condense this description and only reference previous discussions to put a main focus on what this patch actually does. Like

"
After previous discussions [1, 2, 3] the decision was made to introduce a dedicated system call to cover this use case.

...

[1] https://lkml.kernel.org/r/20190411014353.113252-3-surenb@google.com/
"
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.

           EINTR  The call was interrupted by a signal; see signal(7).

           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.
Hm, I do wonder if it would make sense to have a mode (e.g., via a flag) to reap all but shared memory from a dying process. Future work.
           ENOSYS This system call is not supported by kernels built with no
                  MMU support (CONFIG_MMU=n).
Maybe "This system call is not supported, for example, without MMU support built into Linux."
quoted hunk
           ESRCH  The target process does not exist (i.e., it has terminated
                  and been waited on).

Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
changes in v4:
- Replaced mmap_read_lock() with mmap_read_lock_killable(), per Michal Hocko
- Added EINTR error in the manual pages documentation

  mm/oom_kill.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 58 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index c729a4c4a1ac..86727794b0a8 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>
@@ -1141,3 +1142,60 @@ void pagefault_out_of_memory(void)
  	out_of_memory(&oc);
  	mutex_unlock(&oom_lock);
  }
+
+SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
+{
+#ifdef CONFIG_MMU
+	struct mm_struct *mm = NULL;
+	struct task_struct *task;
+	unsigned int f_flags;
+	struct pid *pid;
+	long ret = 0;
+
+	if (flags != 0)
if (flags)
quoted hunk
+		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;
+	}
+
+	if (mmap_read_lock_killable(mm)) {
+		ret = -EINTR;
+		goto put_mm;
+	}
+	if (!__oom_reap_task_mm(mm))
+		ret = -EAGAIN;
I'm not an expert on __oom_reap_task_mm(), but the whole approach makes sense to. So feel free to add my

Acked-by: David Hildenbrand <redacted>

-- 
Thanks,

David / dhildenb

Re: [PATCH v4 1/2] mm: introduce process_mrelease system call

From: Michal Hocko <mhocko@suse.com>
Date: 2021-08-03 08:39:13

On Mon 02-08-21 15:14:30, 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
Please use the msg-id based urls https://lore.kernel.org/lkml/20190411014353.113252-3-surenb@google.com/
pidfd_send_signal to allow memory reaping using oom_reaper thread;
- https://lore.kernel.org/patchwork/patch/1338196 extending
https://lore.kernel.org/linux-api/20201113173448.1863419-1-surenb@google.com/
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.
https://lore.kernel.org/linux-api/20201124053943.1684874-3-surenb@google.com/
The end of the last discussion culminated with suggestion to introduce a
dedicated system call (https://lore.kernel.org/patchwork/patch/1344418/#1553875)
https://lore.kernel.org/linux-api/20201223075712.GA4719@lst.de/
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
quoted
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.
This is not really precise. The implementation will allow to use the
syscall on any exiting or fatal signal received process. Not just those
that have been SIGKILLed, right? For the purpose of the man page I would
go with exiting process for the wording.
 
          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.

          EINTR  The call was interrupted by a signal; see signal(7).

          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.
again, wording here. I would go with
	    EINVAL The memory of the task cannot be released because the
	           process is not exiting, the address space is shared
		   with an alive process or there is a core dump is in
		   progress..
quoted hunk
          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 <surenb@google.com>
---
changes in v4:
- Replaced mmap_read_lock() with mmap_read_lock_killable(), per Michal Hocko
- Added EINTR error in the manual pages documentation

 mm/oom_kill.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index c729a4c4a1ac..86727794b0a8 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>
@@ -1141,3 +1142,60 @@ void pagefault_out_of_memory(void)
 	out_of_memory(&oc);
 	mutex_unlock(&oom_lock);
 }
+
+SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
+{
+#ifdef CONFIG_MMU
+	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);
Don't we need find_lock_task_mm here?
quoted hunk
+	if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
+		mm = task->mm;
+		mmget(mm);
+	}
+	task_unlock(task);
+	if (!mm) {
Do we want to treat MMF_OOM_SKIP as a failure?
+		ret = -EINVAL;
+		goto put_task;
+	}
+
+	if (mmap_read_lock_killable(mm)) {
+		ret = -EINTR;
+		goto put_mm;
+	}
+	if (!__oom_reap_task_mm(mm))
+		ret = -EAGAIN;
+	mmap_read_unlock(mm);
+
+put_mm:
+	mmput(mm);
+put_task:
+	put_task_struct(task);
+put_pid:
+	put_pid(pid);
+	return ret;
+#else
+	return -ENOSYS;
+#endif /* CONFIG_MMU */
+}
-- 
2.32.0.554.ge1b32706d8-goog
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v4 1/2] mm: introduce process_mrelease system call

From: Suren Baghdasaryan <surenb@google.com>
Date: 2021-08-03 17:19:16

On Tue, Aug 3, 2021 at 12:48 AM David Hildenbrand [off-list ref] wrote:
[...]
quoted
Previously I proposed a number of alternatives to accomplish this:
- https://lore.kernel.org/patchwork/patch/1060407 extending
I have no idea how stable these links are. Referencing via message id is
the common practice. For this link, we'd use

https://lkml.kernel.org/r/20190411014353.113252-3-surenb@google.com/

instead.
Ack.
quoted
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.
I'd condense this description and only reference previous discussions to
put a main focus on what this patch actually does. Like

"
After previous discussions [1, 2, 3] the decision was made to introduce
a dedicated system call to cover this use case.

...

[1] https://lkml.kernel.org/r/20190411014353.113252-3-surenb@google.com/
"
Ack.
quoted
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.

           EINTR  The call was interrupted by a signal; see signal(7).

           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.
Hm, I do wonder if it would make sense to have a mode (e.g., via a flag)
to reap all but shared memory from a dying process. Future work.
Agree. Let's keep it simple for now and will expand when the need arises.
quoted
           ENOSYS This system call is not supported by kernels built with no
                  MMU support (CONFIG_MMU=n).
Maybe "This system call is not supported, for example, without MMU
support built into Linux."
Ack.
quoted
           ESRCH  The target process does not exist (i.e., it has terminated
                  and been waited on).

Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
changes in v4:
- Replaced mmap_read_lock() with mmap_read_lock_killable(), per Michal Hocko
- Added EINTR error in the manual pages documentation

  mm/oom_kill.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 58 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index c729a4c4a1ac..86727794b0a8 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>
@@ -1141,3 +1142,60 @@ void pagefault_out_of_memory(void)
      out_of_memory(&oc);
      mutex_unlock(&oom_lock);
  }
+
+SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
+{
+#ifdef CONFIG_MMU
+     struct mm_struct *mm = NULL;
+     struct task_struct *task;
+     unsigned int f_flags;
+     struct pid *pid;
+     long ret = 0;
+
+     if (flags != 0)
if (flags)
Ack.
quoted
+             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;
+     }
+
+     if (mmap_read_lock_killable(mm)) {
+             ret = -EINTR;
+             goto put_mm;
+     }
+     if (!__oom_reap_task_mm(mm))
+             ret = -EAGAIN;
I'm not an expert on __oom_reap_task_mm(), but the whole approach makes
sense to. So feel free to add my

Acked-by: David Hildenbrand <redacted>
Thanks! I see Michal also asked for some documentation changes and a
simple code change, so I won't roll your Acked-by automatically into
the next version but would appreciate it on the final version :)
Will post the next rev later today or tomorrow morning.
Thanks for the review!
--
Thanks,

David / dhildenb

Re: [PATCH v4 1/2] mm: introduce process_mrelease system call

From: Suren Baghdasaryan <surenb@google.com>
Date: 2021-08-03 17:28:00

On Tue, Aug 3, 2021 at 1:39 AM Michal Hocko [off-list ref] wrote:
On Mon 02-08-21 15:14:30, Suren Baghdasaryan wrote:
quoted
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
Please use the msg-id based urls https://lore.kernel.org/lkml/20190411014353.113252-3-surenb@google.com/
Will do. Thanks!
quoted
pidfd_send_signal to allow memory reaping using oom_reaper thread;
- https://lore.kernel.org/patchwork/patch/1338196 extending
https://lore.kernel.org/linux-api/20201113173448.1863419-1-surenb@google.com/
quoted
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.
https://lore.kernel.org/linux-api/20201124053943.1684874-3-surenb@google.com/
quoted
The end of the last discussion culminated with suggestion to introduce a
dedicated system call (https://lore.kernel.org/patchwork/patch/1344418/#1553875)
https://lore.kernel.org/linux-api/20201223075712.GA4719@lst.de/
quoted
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
quoted
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.
This is not really precise. The implementation will allow to use the
syscall on any exiting or fatal signal received process. Not just those
that have been SIGKILLed, right? For the purpose of the man page I would
go with exiting process for the wording.
Ack.
quoted
          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.

          EINTR  The call was interrupted by a signal; see signal(7).

          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.
again, wording here. I would go with
            EINVAL The memory of the task cannot be released because the
                   process is not exiting, the address space is shared
                   with an alive process or there is a core dump is in
                   progress..
Ack.
quoted
          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 <surenb@google.com>
---
changes in v4:
- Replaced mmap_read_lock() with mmap_read_lock_killable(), per Michal Hocko
- Added EINTR error in the manual pages documentation

 mm/oom_kill.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index c729a4c4a1ac..86727794b0a8 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>
@@ -1141,3 +1142,60 @@ void pagefault_out_of_memory(void)
      out_of_memory(&oc);
      mutex_unlock(&oom_lock);
 }
+
+SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
+{
+#ifdef CONFIG_MMU
+     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);
Don't we need find_lock_task_mm here?
Yes, we do. Will fix in the next rev.
quoted
+     if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
+             mm = task->mm;
+             mmget(mm);
+     }
+     task_unlock(task);
+     if (!mm) {
Do we want to treat MMF_OOM_SKIP as a failure?
Yeah, I don't think we want to create additional contention if
oom-killer is already working on this mm. Should we return EBUSY in
this case? Other possible options is ESRCH, indicating that this
process is a goner, so don't bother. WDYT?
quoted
+             ret = -EINVAL;
+             goto put_task;
+     }
+
+     if (mmap_read_lock_killable(mm)) {
+             ret = -EINTR;
+             goto put_mm;
+     }
+     if (!__oom_reap_task_mm(mm))
+             ret = -EAGAIN;
+     mmap_read_unlock(mm);
+
+put_mm:
+     mmput(mm);
+put_task:
+     put_task_struct(task);
+put_pid:
+     put_pid(pid);
+     return ret;
+#else
+     return -ENOSYS;
+#endif /* CONFIG_MMU */
+}
--
2.32.0.554.ge1b32706d8-goog
Thanks for the review!
--
Michal Hocko
SUSE Labs

Re: [PATCH v4 1/2] mm: introduce process_mrelease system call

From: Suren Baghdasaryan <surenb@google.com>
Date: 2021-08-03 22:09:58

On Tue, Aug 3, 2021 at 10:27 AM Suren Baghdasaryan [off-list ref] wrote:
On Tue, Aug 3, 2021 at 1:39 AM Michal Hocko [off-list ref] wrote:
quoted
On Mon 02-08-21 15:14:30, Suren Baghdasaryan wrote:
quoted
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
Please use the msg-id based urls https://lore.kernel.org/lkml/20190411014353.113252-3-surenb@google.com/
Will do. Thanks!
quoted
quoted
pidfd_send_signal to allow memory reaping using oom_reaper thread;
- https://lore.kernel.org/patchwork/patch/1338196 extending
https://lore.kernel.org/linux-api/20201113173448.1863419-1-surenb@google.com/
quoted
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.
https://lore.kernel.org/linux-api/20201124053943.1684874-3-surenb@google.com/
quoted
The end of the last discussion culminated with suggestion to introduce a
dedicated system call (https://lore.kernel.org/patchwork/patch/1344418/#1553875)
https://lore.kernel.org/linux-api/20201223075712.GA4719@lst.de/
quoted
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
quoted
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.
This is not really precise. The implementation will allow to use the
syscall on any exiting or fatal signal received process. Not just those
that have been SIGKILLed, right? For the purpose of the man page I would
go with exiting process for the wording.
Ack.
quoted
quoted
          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.

          EINTR  The call was interrupted by a signal; see signal(7).

          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.
again, wording here. I would go with
            EINVAL The memory of the task cannot be released because the
                   process is not exiting, the address space is shared
                   with an alive process or there is a core dump is in
                   progress..
Ack.
quoted
quoted
          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 <surenb@google.com>
---
changes in v4:
- Replaced mmap_read_lock() with mmap_read_lock_killable(), per Michal Hocko
- Added EINTR error in the manual pages documentation

 mm/oom_kill.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index c729a4c4a1ac..86727794b0a8 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>
@@ -1141,3 +1142,60 @@ void pagefault_out_of_memory(void)
      out_of_memory(&oc);
      mutex_unlock(&oom_lock);
 }
+
+SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
+{
+#ifdef CONFIG_MMU
+     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);
Don't we need find_lock_task_mm here?
Yes, we do. Will fix in the next rev.
quoted
quoted
+     if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
+             mm = task->mm;
+             mmget(mm);
+     }
+     task_unlock(task);
+     if (!mm) {
Do we want to treat MMF_OOM_SKIP as a failure?
Yeah, I don't think we want to create additional contention if
oom-killer is already working on this mm. Should we return EBUSY in
this case? Other possible options is ESRCH, indicating that this
process is a goner, so don't bother. WDYT?
After considering this some more I think ESRCH would be more
appropriate. EBUSY might be understood as "I need to retry at a better
time", which is not what we want here.
I posted v5 at https://lore.kernel.org/patchwork/patch/1471926 with
suggested changes.
Thanks,
Suren.
quoted
quoted
+             ret = -EINVAL;
+             goto put_task;
+     }
+
+     if (mmap_read_lock_killable(mm)) {
+             ret = -EINTR;
+             goto put_mm;
+     }
+     if (!__oom_reap_task_mm(mm))
+             ret = -EAGAIN;
+     mmap_read_unlock(mm);
+
+put_mm:
+     mmput(mm);
+put_task:
+     put_task_struct(task);
+put_pid:
+     put_pid(pid);
+     return ret;
+#else
+     return -ENOSYS;
+#endif /* CONFIG_MMU */
+}
--
2.32.0.554.ge1b32706d8-goog
Thanks for the review!
quoted
--
Michal Hocko
SUSE Labs

Re: [PATCH v4 1/2] mm: introduce process_mrelease system call

From: Michal Hocko <mhocko@suse.com>
Date: 2021-08-04 06:21:25

On Tue 03-08-21 15:09:43, Suren Baghdasaryan wrote:
On Tue, Aug 3, 2021 at 10:27 AM Suren Baghdasaryan [off-list ref] wrote:
[...]
quoted
quoted
quoted
+     if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
+             mm = task->mm;
+             mmget(mm);
+     }
+     task_unlock(task);
+     if (!mm) {
Do we want to treat MMF_OOM_SKIP as a failure?
Yeah, I don't think we want to create additional contention if
oom-killer is already working on this mm. Should we return EBUSY in
this case? Other possible options is ESRCH, indicating that this
process is a goner, so don't bother. WDYT?
After considering this some more I think ESRCH would be more
appropriate. EBUSY might be understood as "I need to retry at a better
time", which is not what we want here.
Why cannot we simply return 0 in that case. The work has been done
already by the kernel so why should we tell the caller that there was
something wrong?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v4 1/2] mm: introduce process_mrelease system call

From: Suren Baghdasaryan <surenb@google.com>
Date: 2021-08-04 16:54:31

On Tue, Aug 3, 2021 at 11:21 PM Michal Hocko [off-list ref] wrote:
On Tue 03-08-21 15:09:43, Suren Baghdasaryan wrote:
quoted
On Tue, Aug 3, 2021 at 10:27 AM Suren Baghdasaryan [off-list ref] wrote:
[...]
quoted
quoted
quoted
quoted
+     if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
+             mm = task->mm;
+             mmget(mm);
+     }
+     task_unlock(task);
+     if (!mm) {
Do we want to treat MMF_OOM_SKIP as a failure?
Yeah, I don't think we want to create additional contention if
oom-killer is already working on this mm. Should we return EBUSY in
this case? Other possible options is ESRCH, indicating that this
process is a goner, so don't bother. WDYT?
After considering this some more I think ESRCH would be more
appropriate. EBUSY might be understood as "I need to retry at a better
time", which is not what we want here.
Why cannot we simply return 0 in that case. The work has been done
already by the kernel so why should we tell the caller that there was
something wrong?
Ah, you are right. I was under the impression that MMF_OOM_SKIP means
oom-killer is reaping the mm, but looks like it means that mm was
already reaped. If that's true then I agree, returning 0 is the right
move here. Will fix.
--
Michal Hocko
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help