The patch titled
Subject: mm: treat indirectly reclaimable memory as free in overcommit logic
has been added to the -mm tree. Its filename is
mm-treat-indirectly-reclaimable-memory-as-free-in-overcommit-logic.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-treat-indirectly-reclaimable-memory-as-free-in-overcommit-logic.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-treat-indirectly-reclaimable-memory-as-free-in-overcommit-logic.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Roman Gushchin <guro@xxxxxx>
Subject: mm: treat indirectly reclaimable memory as free in overcommit logic
Indirectly reclaimable memory can consume a significant part of total
memory and it's actually reclaimable (it will be released under actual
memory pressure).
So, the overcommit logic should treat it as free.
Otherwise, it's possible to cause random system-wide memory allocation
failures by consuming a significant amount of memory by indirectly
reclaimable memory, e.g. dentry external names.
If overcommit policy GUESS is used, it might be used for denial of service
attack under some conditions.
The following program illustrates the approach. It causes the kernel to
allocate an unreclaimable kmalloc-256 chunk for each stat() call, so that
at some point the overcommit logic may start blocking large allocation
system-wide.
int main()
{
char buf[256];
unsigned long i;
struct stat statbuf;
buf[0] = '/';
for (i = 1; i < sizeof(buf); i++)
buf[i] = '_';
for (i = 0; 1; i++) {
sprintf(&buf[248], "%8lu", i);
stat(buf, &statbuf);
}
return 0;
}
This patch in combination with related indirectly reclaimable memory
patches closes this issue.
Link: http://lkml.kernel.org/r/20180313130041.8078-1-guro@xxxxxx
Signed-off-by: Roman Gushchin <guro@xxxxxx>
Reviewed-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/util.c | 7 +++++++
1 file changed, 7 insertions(+)
diff -puN mm/util.c~mm-treat-indirectly-reclaimable-memory-as-free-in-overcommit-logic mm/util.c
--- a/mm/util.c~mm-treat-indirectly-reclaimable-memory-as-free-in-overcommit-logic
+++ a/mm/util.c
@@ -658,6 +658,13 @@ int __vm_enough_memory(struct mm_struct
free += global_node_page_state(NR_SLAB_RECLAIMABLE);
/*
+ * Part of the kernel memory, which can be released
+ * under memory pressure.
+ */
+ free += global_node_page_state(
+ NR_INDIRECTLY_RECLAIMABLE_BYTES) >> PAGE_SHIFT;
+
+ /*
* Leave reserved pages. The pages are not for anonymous pages.
*/
if (free <= totalreserve_pages)
_
Patches currently in -mm which might be from guro@xxxxxx are
mm-introduce-nr_indirectly_reclaimable_bytes.patch
mm-treat-indirectly-reclaimable-memory-as-available-in-memavailable.patch
dcache-account-external-names-as-indirectly-reclaimable-memory.patch
dcache-account-external-names-as-indirectly-reclaimable-memory-fix.patch
mm-treat-indirectly-reclaimable-memory-as-free-in-overcommit-logic.patch
mm-oom-refactor-the-oom_kill_process-function.patch
mm-implement-mem_cgroup_scan_tasks-for-the-root-memory-cgroup.patch
mm-oom-cgroup-aware-oom-killer.patch
mm-oom-introduce-memoryoom_group.patch
mm-oom-introduce-memoryoom_group-fix.patch
mm-oom-add-cgroup-v2-mount-option-for-cgroup-aware-oom-killer.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix.patch
cgroup-list-groupoom-in-cgroup-features.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
