From: Vlastimil Babka <vbabka@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Harry Yoo <harry.yoo@oracle.com>
Cc: Uladzislau Rezki <urezki@gmail.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Suren Baghdasaryan <surenb@google.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Alexei Starovoitov <ast@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev, bpf@vger.kernel.org,
kasan-dev@googlegroups.com, Vlastimil Babka <vbabka@suse.cz>
Subject: [PATCH RFC 04/19] slab: prevent recursive kmalloc() in alloc_empty_sheaf()
Date: Thu, 23 Oct 2025 15:52:26 +0200 [thread overview]
Message-ID: <20251023-sheaves-for-all-v1-4-6ffa2c9941c0@suse.cz> (raw)
In-Reply-To: <20251023-sheaves-for-all-v1-0-6ffa2c9941c0@suse.cz>
We want to expand usage of sheaves to all non-boot caches, including
kmalloc caches. Since sheaves themselves are also allocated by
kmalloc(), we need to prevent excessive or infinite recursion -
depending on sheaf size, the sheaf can be allocated from smaller, same
or larger kmalloc size bucket, there's no particular constraint.
This is similar to allocating the objext arrays so let's just reuse the
existing mechanisms for those. __GFP_NO_OBJ_EXT in alloc_empty_sheaf()
will prevent a nested kmalloc() from allocating a sheaf itself - it will
either have sheaves already, or fallback to a non-sheaf-cached
allocation (so bootstrap of sheaves in a kmalloc cache that allocates
sheaves from its own size bucket is possible). Additionally, reuse
OBJCGS_CLEAR_MASK to clear unwanted gfp flags from the nested
allocation.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
include/linux/gfp_types.h | 6 ------
mm/slub.c | 36 ++++++++++++++++++++++++++----------
2 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index 65db9349f905..3de43b12209e 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -55,9 +55,7 @@ enum {
#ifdef CONFIG_LOCKDEP
___GFP_NOLOCKDEP_BIT,
#endif
-#ifdef CONFIG_SLAB_OBJ_EXT
___GFP_NO_OBJ_EXT_BIT,
-#endif
___GFP_LAST_BIT
};
@@ -98,11 +96,7 @@ enum {
#else
#define ___GFP_NOLOCKDEP 0
#endif
-#ifdef CONFIG_SLAB_OBJ_EXT
#define ___GFP_NO_OBJ_EXT BIT(___GFP_NO_OBJ_EXT_BIT)
-#else
-#define ___GFP_NO_OBJ_EXT 0
-#endif
/*
* Physical address zone modifiers (see linux/mmzone.h - low four bits)
diff --git a/mm/slub.c b/mm/slub.c
index 68867cd52c4f..f2b2a6180759 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2031,6 +2031,14 @@ static bool freelist_corrupted(struct kmem_cache *s, struct slab *slab,
}
#endif /* CONFIG_SLUB_DEBUG */
+/*
+ * The allocated objcg pointers array is not accounted directly.
+ * Moreover, it should not come from DMA buffer and is not readily
+ * reclaimable. So those GFP bits should be masked off.
+ */
+#define OBJCGS_CLEAR_MASK (__GFP_DMA | __GFP_RECLAIMABLE | \
+ __GFP_ACCOUNT | __GFP_NOFAIL)
+
#ifdef CONFIG_SLAB_OBJ_EXT
#ifdef CONFIG_MEM_ALLOC_PROFILING_DEBUG
@@ -2081,14 +2089,6 @@ static inline void handle_failed_objexts_alloc(unsigned long obj_exts,
#endif /* CONFIG_MEM_ALLOC_PROFILING_DEBUG */
-/*
- * The allocated objcg pointers array is not accounted directly.
- * Moreover, it should not come from DMA buffer and is not readily
- * reclaimable. So those GFP bits should be masked off.
- */
-#define OBJCGS_CLEAR_MASK (__GFP_DMA | __GFP_RECLAIMABLE | \
- __GFP_ACCOUNT | __GFP_NOFAIL)
-
static inline void init_slab_obj_exts(struct slab *slab)
{
slab->obj_exts = 0;
@@ -2590,8 +2590,24 @@ static void *setup_object(struct kmem_cache *s, void *object)
static struct slab_sheaf *alloc_empty_sheaf(struct kmem_cache *s, gfp_t gfp)
{
- struct slab_sheaf *sheaf = kzalloc(struct_size(sheaf, objects,
- s->sheaf_capacity), gfp);
+ struct slab_sheaf *sheaf;
+ size_t sheaf_size;
+
+ if (gfp & __GFP_NO_OBJ_EXT)
+ return NULL;
+
+ gfp &= ~OBJCGS_CLEAR_MASK;
+
+ /*
+ * Prevent recursion to the same cache, or a deep stack of kmallocs of
+ * varying sizes (sheaf capacity might differ for each kmalloc size
+ * bucket)
+ */
+ if (s->flags & SLAB_KMALLOC)
+ gfp |= __GFP_NO_OBJ_EXT;
+
+ sheaf_size = struct_size(sheaf, objects, s->sheaf_capacity);
+ sheaf = kzalloc(sheaf_size, gfp);
if (unlikely(!sheaf))
return NULL;
--
2.51.1
next prev parent reply other threads:[~2025-10-23 13:53 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 13:52 [PATCH RFC 00/19] slab: replace cpu (partial) slabs with sheaves Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 01/19] slab: move kfence_alloc() out of internal bulk alloc Vlastimil Babka
2025-10-23 15:20 ` Marco Elver
2025-10-29 14:38 ` Vlastimil Babka
2025-10-29 15:30 ` Marco Elver
2025-10-23 13:52 ` [PATCH RFC 02/19] slab: handle pfmemalloc slabs properly with sheaves Vlastimil Babka
2025-10-24 14:21 ` Chris Mason
2025-10-29 15:00 ` Vlastimil Babka
2025-10-29 16:06 ` Chris Mason
2025-10-23 13:52 ` [PATCH RFC 03/19] slub: remove CONFIG_SLUB_TINY specific code paths Vlastimil Babka
2025-10-24 22:34 ` Alexei Starovoitov
2025-10-29 15:37 ` Vlastimil Babka
2025-10-23 13:52 ` Vlastimil Babka [this message]
2025-10-23 13:52 ` [PATCH RFC 05/19] slab: add sheaves to most caches Vlastimil Babka
2025-10-27 0:24 ` Harry Yoo
2025-10-29 15:42 ` Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 06/19] slab: introduce percpu sheaves bootstrap Vlastimil Babka
2025-10-24 15:29 ` Chris Mason
2025-10-29 15:51 ` Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 07/19] slab: make percpu sheaves compatible with kmalloc_nolock()/kfree_nolock() Vlastimil Babka
2025-10-24 14:04 ` Chris Mason
2025-10-29 17:30 ` Vlastimil Babka
2025-10-24 19:43 ` Alexei Starovoitov
2025-10-29 17:46 ` Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 08/19] slab: handle kmalloc sheaves bootstrap Vlastimil Babka
2025-10-27 6:12 ` Harry Yoo
2025-10-29 20:06 ` Vlastimil Babka
2025-10-29 20:06 ` Vlastimil Babka
2025-10-30 0:11 ` Harry Yoo
2025-10-23 13:52 ` [PATCH RFC 09/19] slab: add optimized sheaf refill from partial list Vlastimil Babka
2025-10-27 7:20 ` Harry Yoo
2025-10-27 9:11 ` Harry Yoo
2025-10-29 20:48 ` Vlastimil Babka
2025-10-30 0:07 ` Harry Yoo
2025-10-30 13:18 ` Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 10/19] slab: remove cpu (partial) slabs usage from allocation paths Vlastimil Babka
2025-10-24 14:29 ` Chris Mason
2025-10-29 21:31 ` Vlastimil Babka
2025-10-30 4:32 ` Harry Yoo
2025-10-30 13:09 ` Vlastimil Babka
2025-10-30 15:27 ` Alexei Starovoitov
2025-10-30 15:35 ` Vlastimil Babka
2025-10-30 15:59 ` Alexei Starovoitov
2025-11-03 3:44 ` Harry Yoo
2025-10-23 13:52 ` [PATCH RFC 11/19] slab: remove SLUB_CPU_PARTIAL Vlastimil Babka
2025-10-24 20:43 ` Alexei Starovoitov
2025-10-29 22:31 ` Vlastimil Babka
2025-10-30 0:26 ` Alexei Starovoitov
2025-10-23 13:52 ` [PATCH RFC 12/19] slab: remove the do_slab_free() fastpath Vlastimil Babka
2025-10-24 22:32 ` Alexei Starovoitov
2025-10-29 22:44 ` Vlastimil Babka
2025-10-30 0:24 ` Alexei Starovoitov
2025-10-23 13:52 ` [PATCH RFC 13/19] slab: remove defer_deactivate_slab() Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 14/19] slab: simplify kmalloc_nolock() Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 15/19] slab: remove struct kmem_cache_cpu Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 16/19] slab: remove unused PREEMPT_RT specific macros Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 17/19] slab: refill sheaves from all nodes Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 18/19] slab: update overview comments Vlastimil Babka
2025-10-23 13:52 ` [PATCH RFC 19/19] slab: remove frozen slab checks from __slab_free() Vlastimil Babka
2025-10-24 23:57 ` [PATCH RFC 00/19] slab: replace cpu (partial) slabs with sheaves Alexei Starovoitov
2025-11-04 22:11 ` Christoph Lameter (Ampere)
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=20251023-sheaves-for-all-v1-4-6ffa2c9941c0@suse.cz \
--to=vbabka@suse.cz \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=bpf@vger.kernel.org \
--cc=cl@gentwo.org \
--cc=harry.yoo@oracle.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=surenb@google.com \
--cc=urezki@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