From: Harry Yoo <harry@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Hao Li <hao.li@linux.dev>, Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
"Liam R. Howlett" <liam@infradead.org>, Hao Ge <hao.ge@linux.dev>,
Kees Cook <kees@kernel.org>, Pedro Falcato <pfalcato@suse.de>,
Shakeel Butt <shakeel.butt@linux.dev>,
Danielle Constantino <dcostantino@meta.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH slab/for-next-fixes v3 4/4] mm/slab: prevent unbounded recursion in free path with new kmalloc type
Date: Tue, 14 Jul 2026 14:17:16 +0900 [thread overview]
Message-ID: <121dda1a-f050-4035-93c0-6a36278e50b7@kernel.org> (raw)
In-Reply-To: <CAJuCfpFda=dEfW5Cr6ZPfOEq4nwgX-zox=QNTHc_hum07mFH2g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5461 bytes --]
On 7/14/26 2:08 AM, Suren Baghdasaryan wrote:
> On Mon, Jul 13, 2026 at 7:29 AM Harry Yoo (Oracle) <harry@kernel.org> wrote:
>> @@ -386,12 +387,17 @@ static inline unsigned int size_index_elem(unsigned int bytes)
>> * KMALLOC_MAX_CACHE_SIZE and the caller must check that.
>> */
>> static inline struct kmem_cache *
>> -kmalloc_slab(size_t size, kmem_buckets *b, gfp_t flags, kmalloc_token_t token)
>> +kmalloc_slab(size_t size, kmem_buckets *b, gfp_t flags, kmalloc_token_t token,
>> + unsigned int alloc_flags)
>> {
>> unsigned int index;
>> + enum kmalloc_cache_type type = kmalloc_type(flags, token);
>> +
>> + if (alloc_flags & SLAB_ALLOC_NO_OBJ_EXT)
>> + type = KMALLOC_NO_OBJ_EXT;
Hi Suren, thanks for the reviews.
It's indeed helpful to have an eye for those bugfixes.
> Why not let kmalloc_type() handle alloc_flags?
Good point!
> Other users (there are
> only 4 of them) can pass SLAB_ALLOC_DEFAULT. That seems cleaner to me
> and more robust.
Hmm, there was a reason... *checks notes*, oh, there is no note.
IIRC I was afraid of exposing SLAB_ALLOC_* flags to arbitrary users.
should probably fine as long as it's not used in
kmalloc/kmem_cache_alloc() APIs, not sure.
>> if (!b)
>> - b = &kmalloc_caches[kmalloc_type(flags, token)];
>> + b = &kmalloc_caches[type];
>> if (size <= 192)
>> index = kmalloc_size_index[size_index_elem(size)];
>> else
>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>> index b6426d7ceec9..03ecac12cd86 100644
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -957,6 +968,12 @@ new_kmalloc_cache(int idx, enum kmalloc_cache_type type)
>> return;
>> }
>> flags |= SLAB_ACCOUNT;
>> + } else if (IS_ENABLED(CONFIG_SLAB_OBJ_EXT) && type == KMALLOC_NO_OBJ_EXT) {
>
> Hmm, you have to check IS_ENABLED(CONFIG_SLAB_OBJ_EXT) here because
> KMALLOC_NO_OBJ_EXT can be aliased with KMALLOC_NORMAL... Could we
> instead have a helper function like this (maybe with a better name):
Hmm that's fine, but I think that bit should not be part of -stable
fixes at least. Here I tried to make it consistent with KMALLOC_RECLAIM
and KMALLOC_DMA :)
> #ifdef CONFIG_SLAB_OBJ_EXT
> bool is_kmalloc_no_obj_ext_type(type) { return type == KMALLOC_NO_OBJ_EXT; }
> #else
> bool is_kmalloc_no_obj_ext_type(type) { return false; }
> #endif
> ?
is_kmalloc_no_obj_ext_type(),
kmalloc_type_is_no_obj_ext(),
is_kmalloc_type_no_obj_ext(),
...
naming is hard, ugh :)
>
>> + if (!need_kmalloc_no_objext()) {
>> + kmalloc_caches[type][idx] = kmalloc_caches[KMALLOC_NORMAL][idx];
>
> Could kmalloc_caches[KMALLOC_NORMAL][idx] be NULL here?
No. KMALLOC_NORMAL caches are created before all other kmalloc
caches.
IIRC checking if kmalloc_caches[KMALLOC_NORMAL][idx] is NULL was added
by commit 963e84b0f262 ("mm/slab: limit kmalloc() minimum alignment
to dma_get_cache_alignment()") to avoid creating kmalloc caches of same
type and size due to minimum alignment.
> In general why do we special-case and do an early exit here?
>
> Can we do instead:
>
> if (need_kmalloc_no_objext())
> flags |= SLAB_NO_OBJ_EXT | SLAB_NO_MERGE;
>
> and use the common path?
Hmm, but even without SLAB_NO_MERGE, we often end up not merging
kmalloc caches e.g.) because of non-zero s->usersize.
I think that's why we do special-case and an early exit?
We could probably do some refactoring to change that, but in general
I'm afraid of backporting refactoring work to -stable because I fear
introducing very subtle behavioral changes that nobody would notice.
>> + return;
>> + }
>> + flags |= SLAB_NO_OBJ_EXT | SLAB_NO_MERGE;
>> } else if (IS_ENABLED(CONFIG_ZONE_DMA) && (type == KMALLOC_DMA)) {
>> flags |= SLAB_CACHE_DMA;
>> }
>> diff --git a/mm/slub.c b/mm/slub.c
>> index abe748b7dddb..a34f9b8770dc 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -2168,14 +2132,20 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
>> unsigned long new_exts;
>> unsigned long old_exts;
>> struct slabobj_ext *vec;
>> - size_t sz;
>> + size_t sz = sizeof(struct slabobj_ext) * slab->objects;
>>
>> gfp &= ~OBJCGS_CLEAR_MASK;
>> - /* Prevent recursive extension vector allocation */
>> - alloc_flags |= SLAB_ALLOC_NO_RECURSE;
>> - alloc_flags &= ~SLAB_ALLOC_NEW_SLAB;
>> + /*
>> + * In most cases, obj_exts arrays are allocated from normal kmalloc.
>> + * However, normal kmalloc caches must allocate them from
>> + * KMALLOC_NO_OBJ_EXT caches to prevent recursion.
>
> For debugging it would have been convenient to allocate all obj_ext
> vectors from dedicated caches... Maybe we can do that for
> CONFIG_DEBUG_VM or someday when we add CONFIG_OBJ_EXT_DEBUG? Anyway,
> not really a complaint but a wish.
Vlastimil and I had a conversation on always (even w/o debug options)
having dedicated caches (primarily to separate lifetime and for
simplicity), it would be interesting to explore.
https://lore.kernel.org/all/2436707a-b6ab-45ec-98e5-538e18589462@kernel.org
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-07-14 5:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 14:28 [PATCH slab/for-next-fixes v3 0/4] mm/slab: fix unbounded recursion in free path with memalloc profiling Harry Yoo (Oracle)
2026-07-13 14:28 ` [PATCH slab/for-next-fixes v3 1/4] mm/slab: fix a memory leak due to bootstrapping sheaves twice Harry Yoo (Oracle)
2026-07-13 15:30 ` Suren Baghdasaryan
2026-07-16 2:31 ` Harry Yoo
2026-07-13 14:28 ` [PATCH slab/for-next-fixes v3 2/4] mm/slab: decouple SLAB_NO_SHEAVES from SLAB_NO_OBJ_EXT Harry Yoo (Oracle)
2026-07-13 15:37 ` Suren Baghdasaryan
2026-07-13 14:28 ` [PATCH slab/for-next-fixes v3 3/4] lib/alloc_tag: introduce mem_alloc_profiling_permanently_disabled() Harry Yoo (Oracle)
2026-07-13 15:43 ` Suren Baghdasaryan
2026-07-13 16:15 ` Vlastimil Babka (SUSE)
2026-07-13 16:28 ` Harry Yoo
2026-07-14 14:37 ` Suren Baghdasaryan
2026-07-16 2:34 ` Harry Yoo
2026-07-13 14:28 ` [PATCH slab/for-next-fixes v3 4/4] mm/slab: prevent unbounded recursion in free path with new kmalloc type Harry Yoo (Oracle)
2026-07-13 17:08 ` Suren Baghdasaryan
2026-07-14 5:17 ` Harry Yoo [this message]
2026-07-14 9:12 ` Vlastimil Babka (SUSE)
2026-07-14 14:27 ` Suren Baghdasaryan
2026-07-14 15:21 ` Vlastimil Babka (SUSE)
2026-07-14 15:42 ` [PATCH slab/for-next-fixes v3 0/4] mm/slab: fix unbounded recursion in free path with memalloc profiling Vlastimil Babka (SUSE)
2026-07-15 7:46 ` Harry Yoo
2026-07-16 18:05 ` Shakeel Butt
2026-07-17 4:09 ` Harry Yoo
2026-07-16 19:37 ` Shakeel Butt
2026-07-17 1:16 ` Hao Ge
2026-07-17 15:18 ` Shakeel Butt
2026-07-17 4:10 ` Harry Yoo
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=121dda1a-f050-4035-93c0-6a36278e50b7@kernel.org \
--to=harry@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=dcostantino@meta.com \
--cc=hao.ge@linux.dev \
--cc=hao.li@linux.dev \
--cc=kees@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pfalcato@suse.de \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/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