linux-kernel - [PATCH] mm, page_alloc: actually ignore mempolicies for high priority allocations

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20180612122624.8045-1-vbabka@suse.cz>
Date:   Tue, 12 Jun 2018 14:26:24 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org, Vlastimil Babka <vbabka@...e.cz>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Michal Hocko <mhocko@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: [PATCH] mm, page_alloc: actually ignore mempolicies for high priority allocations

The __alloc_pages_slowpath() function has for a long time contained code to
ignore node restrictions from memory policies for high priority allocations.
The current code that resets the zonelist iterator however does effectively
nothing after commit 7810e6781e0f ("mm, page_alloc: do not break __GFP_THISNODE
by zonelist reset") removed a buggy zonelist reset. Even before that commit,
mempolicy restrictions were still not ignored, as they are passed in
ac->nodemask which is untouched by the code.

We can either remove the code, or make it work as intended. Since
ac->nodemask can be set from task's mempolicy via alloc_pages_current() and
thus also alloc_pages(), it may indeed affect kernel allocations, and it makes
sense to ignore it to allow progress for high priority allocations.

Thus, this patch resets ac->nodemask to NULL in such cases. This assumes all
callers can handle it (i.e. there are no guarantees as in the case of
__GFP_THISNODE) which seems to be the case. The same assumption is already
present in check_retry_cpuset() for some time.

The expected effect is that high priority kernel allocations in the context of
userspace tasks (e.g. OOM victims) restricted by mempolicies will have higher
chance to succeed if they are restricted to nodes with depleted memory, while
there are other nodes with free memory left.

Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
Cc: Mel Gorman <mgorman@...hsingularity.net>
Cc: Michal Hocko <mhocko@...nel.org>
Cc: David Rientjes <rientjes@...gle.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@....com>
---
 mm/page_alloc.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 07b3c23762ad..ec8c92ff8b3c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4164,11 +4164,12 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
 		alloc_flags = reserve_flags;

 	/*
-	 * Reset the zonelist iterators if memory policies can be ignored.
-	 * These allocations are high priority and system rather than user
-	 * orientated.
+	 * Reset the nodemask and zonelist iterators if memory policies can be
+	 * ignored. These allocations are high priority and system rather than
+	 * user oriented.
 	 */
 	if (!(alloc_flags & ALLOC_CPUSET) || reserve_flags) {
+		ac->nodemask = NULL;
 		ac->preferred_zoneref = first_zones_zonelist(ac->zonelist,
 					ac->high_zoneidx, ac->nodemask);
 	}
-- 
2.17.1