linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ohhoon Kwon <ohkwon1043@gmail.com>
To: Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Roman Gushchin <roman.gushchin@linux.dev>
Cc: Ohhoon Kwon <ohkwon1043@gmail.com>,
	JaeSang Yoo <jsyoo5b@gmail.com>,
	Wonhyuk Yang <vvghjk1234@gmail.com>,
	Jiyoup Kim <lakroforce@gmail.com>,
	Donghyeok Kim <dthex5d@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH] mm/slub: check pfmemalloc_match in slab_alloc_node fastpath
Date: Sun, 10 Apr 2022 01:02:23 +0900	[thread overview]
Message-ID: <20220409160224.611353-1-ohkwon1043@gmail.com> (raw)

If current alloc context does not have __GFP_MEMALLOC in its gfpflags,
then slab objects that were previously created with __GFP_MEMALLOC
should not be given.

This criteria is well kept in slab alloc slowpath:
When gfpflags does not contain __GFP_MEMALLOC but if per-cpu slab page
was allocated with __GFP_MEMALLOC, then allocator first deactivates
per-cpu slab page and then again allocates new slab page with the
current context's gfpflags.

However, this criteria is not checked in fastpath.
It should also be checked in the fastpath, too.

Signed-off-by: Ohhoon Kwon <ohkwon1043@gmail.com>
---
 mm/slub.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/slub.c b/mm/slub.c
index 74d92aa4a3a2..c77cd548e106 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3179,7 +3179,8 @@ static __always_inline void *slab_alloc_node(struct kmem_cache *s, struct list_l
 	 * there is a suitable cpu freelist.
 	 */
 	if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
-	    unlikely(!object || !slab || !node_match(slab, node))) {
+	    unlikely(!object || !slab || !node_match(slab, node) ||
+			!pfmemalloc_match(slab, gfpflags))) {
 		object = __slab_alloc(s, gfpflags, node, addr, c);
 	} else {
 		void *next_object = get_freepointer_safe(s, object);
-- 
2.25.1



             reply	other threads:[~2022-04-09 16:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-09 16:02 Ohhoon Kwon [this message]
2022-04-10  8:12 ` Hyeonggon Yoo
2022-04-10 16:13   ` Ohoon Kwon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220409160224.611353-1-ohkwon1043@gmail.com \
    --to=ohkwon1043@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=dthex5d@gmail.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jsyoo5b@gmail.com \
    --cc=lakroforce@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    --cc=vvghjk1234@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox