From: Harry Yoo <harry.yoo@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org, cl@gentwo.org,
rientjes@google.com, surenb@google.com, hao.li@linux.dev,
kernel test robot <oliver.sang@intel.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] mm/slab: avoid allocating slabobj_ext array from its own slab
Date: Mon, 26 Jan 2026 17:57:51 +0900 [thread overview]
Message-ID: <aXcsjyKFsmeVggp5@hyeyoo> (raw)
In-Reply-To: <55ab1a9b-1d7a-4e7e-b6bc-ee327197dc4b@suse.cz>
On Mon, Jan 26, 2026 at 09:37:29AM +0100, Vlastimil Babka wrote:
> On 1/26/26 09:30, Harry Yoo wrote:
> > On Mon, Jan 26, 2026 at 08:36:16AM +0100, Vlastimil Babka wrote:
> > /*
> > * Calculate the allocation size for slabobj_ext array.
> > *
> > * When memory allocation profiling is enabled, the obj_exts array
> > * could be allocated from the same slab it's being allocated for.
> > * This would prevent the slab from ever being freed because it would
> > * always contain at least one allocated object (its own obj_exts array).
> > *
> > * To avoid this, increase the allocation size when we detect the array
> > * would come from the same cache, forcing it to use a different cache.
> > */
> > static inline size_t obj_exts_alloc_size(struct kmem_cache *s,
> > struct slab *slab, gfp_t gfp)
> > {
> > size_t sz = sizeof(struct slabobj_ext) * slab->objects;
> > struct kmem_cache *obj_exts_cache;
> >
> > /*
> > * slabobj_ext array for KMALLOC_CGROUP allocations
> > * are served from KMALLOC_NORMAL caches.
> > */
> > if (!mem_alloc_profiling_enabled())
> > return sz;
> >
> > if (sz > KMALLOC_MAX_CACHE_SIZE)
> > return sz;
> >
> > if (!is_kmalloc_normal(s))
> > return sz;
> >
> > obj_exts_cache = kmalloc_slab(sz, NULL, gfp, 0);
> > /*
> > * Random kmalloc caches have multiple caches per size, and the cache
>
> Maybe start with something like "We can't simply compare s with
> obj_exts_cache, because..."
>
> > * is selected by the caller address. Since caller address may differ
> > * between kmalloc_slab() and actual allocation, bump size when both
> > * are normal kmalloc caches of same size.
>
> As we don't test the other for normal kmalloc(), anymore this now reads as
> if we forgot to.
Ok, something like this:
"We can't simply compare s with obj_exts_cache, because random kmalloc
caches have multiple caches per size, selected by caller address.
Since caller address may differ between kmalloc_slab() and actual
allocation, bump size when sizes are equal."
> > */
> > if (s->size == obj_exts_cache->size)
> > return s->object_size + 1;
>
> Why switch to size from object_size for the checks? I'd be worried that due
> to debugging etc this can yield wrong results?
Oops, sorry. copied from wrong version of the patch.
Yeah I initially compared size and then switched to object_size for the
reason you mentioned.
> >
> > return sz;
> > }
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2026-01-26 8:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-24 10:46 [PATCH] mm/slab: avoid allocating slabobj_ext array from its own slab Harry Yoo
2026-01-24 10:53 ` Harry Yoo
2026-01-26 0:51 ` Hao Li
2026-01-26 13:00 ` Harry Yoo
2026-01-26 14:31 ` Hao Li
2026-01-26 7:36 ` Vlastimil Babka
2026-01-26 8:30 ` Harry Yoo
2026-01-26 8:37 ` Vlastimil Babka
2026-01-26 8:57 ` Harry Yoo [this message]
2026-01-26 9:10 ` Vlastimil Babka
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=aXcsjyKFsmeVggp5@hyeyoo \
--to=harry.yoo@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=hao.li@linux.dev \
--cc=linux-mm@kvack.org \
--cc=oliver.sang@intel.com \
--cc=rientjes@google.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.