linux-kernel - [PATCH] mm/util.c: Add error logs for commitment overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1601639861-32171-1-git-send-email-pintu@codeaurora.org>
Date:   Fri,  2 Oct 2020 17:27:41 +0530
From:   Pintu Kumar <pintu@...eaurora.org>
To:     linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
        linux-mm@...ck.org
Cc:     pintu@...eaurora.org, pintu.ping@...il.com
Subject: [PATCH] mm/util.c: Add error logs for commitment overflow

The headless embedded devices often come with very limited amount
of RAM such as: 256MB or even lesser.
These types of system often rely on command line interface which can
execute system commands in the background using the fork/exec combination.
There could be even many child tasks invoked internally to handle multiple
requests.
In this scenario, if the parent task keeps committing large amount of
memory, there are chances that this commitment can easily overflow the
total RAM available in the system. Now if the parent process invokes fork
or system commands (using system() call) and the commitment ratio is at
50%, the request fails with the following, even though there are large
amount of free memory available in the system:
fork failed: Cannot allocate memory

If there are too many 3rd party tasks calling fork, it becomes difficult to
identify exactly which parent process is overcommitting memory.
Since, free memory is also available, this "Cannot allocate memory" from
fork creates confusion to application developer.

Thus, I found that this simple print message (even once) is helping in
quickly identifying the culprit.

This is the output we can see on a 256MB system and with a simple malloc
and fork program.

[root@ ~]# cat /proc/meminfo
MemTotal:         249520 kB   ==> 243MB
MemFree:          179100 kB

PPID	PID	USER	RSS	VSZ	STAT	ARGS
 150	164	root	1440	250580	S	./consume-and-fork.out 243

__vm_enough_memory: commitment overflow: ppid:150, pid:164, pages:62451
fork failed[count:0]: Cannot allocate memory

Signed-off-by: Pintu Kumar <pintu@...eaurora.org>
---
 mm/util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/util.c b/mm/util.c
index 5ef378a..9431ce7a 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -895,6 +895,9 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
 error:
 	vm_unacct_memory(pages);

+	pr_err_once("%s: commitment overflow: ppid:%d, pid:%d, pages:%ld\n",
+			__func__, current->parent->pid, current->pid, pages);
+
 	return -ENOMEM;
 }

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.