linux-kernel - [PATCH 2/2] mm: warn about ALLOC_NO

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Nov 2015 11:40:54 +0100
From:	Michal Hocko <mhocko@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Mel Gorman <mgorman@...e.de>, David Rientjes <rientjes@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>, <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Michal Hocko <mhocko@...e.com>
Subject: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures

From: Michal Hocko <mhocko@...e.com>

ALLOC_NO_WATERMARKS requests can dive into memory reserves without any
restriction. They are used only in the case of emergency to allow
forward memory reclaim progress assuming the caller should return the
memory in a short time (e.g. {__GFP,PF}_MEMALLOC requests or OOM victim
on the way to exit or __GFP_NOFAIL requests hitting OOM). There is no
guarantee such request succeed because memory reserves might get
depleted as well. This might be either a result of a bug where memory
reserves are abused or a result of a too optimistic configuration of
memory reserves.

This patch makes sure that the administrator gets a warning when these
requests fail with a hint that min_free_kbytes might be used to increase
the amount of memory reserves. The warning might also help us check
whether the issue is caused by a buggy user or the configuration. To
prevent from flooding the logs the warning is on off but we allow it to
trigger again after min_free_kbytes was updated. Something really bad is
clearly going on if the warning hits even after multiple updates of
min_free_kbytes.

Signed-off-by: Michal Hocko <mhocko@...e.com>
---
 mm/page_alloc.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 70db11c27046..6a05d771cb08 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -240,6 +240,8 @@ compound_page_dtor * const compound_page_dtors[] = {
 #endif
 };

+/* warn about depleted watermarks */
+static bool warn_alloc_no_wmarks;
 int min_free_kbytes = 1024;
 int user_min_free_kbytes = -1;

@@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
 	if (zonelist_rescan)
 		goto zonelist_scan;

+	/* WARN only once unless min_free_kbytes is updated */
+	if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) {
+		warn_alloc_no_wmarks = 0;
+		WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x."
+			" You might consider increasing min_free_kbytes\n",
+			order, gfp_mask);
+	}
 	return NULL;
 }

@@ -6048,6 +6057,9 @@ static void __setup_per_zone_wmarks(void)
 	struct zone *zone;
 	unsigned long flags;

+	/* Warn when ALLOC_NO_WATERMARKS request fails */
+	warn_alloc_no_wmarks = 1;
+
 	/* Calculate total number of !ZONE_HIGHMEM pages */
 	for_each_zone(zone) {
 		if (!is_highmem(zone))
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/