From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Harry Yoo <harry@kernel.org>, Hao Li <hao.li@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Alexander Potapenko <glider@google.com>,
Marco Elver <elver@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org
Subject: Re: [PATCH RFC 01/12] mm/slab: skip kfence objects in allocation profiling
Date: Thu, 16 Jul 2026 11:11:06 +0200 [thread overview]
Message-ID: <ab9782bf-d3dd-4cb5-ae66-127b3a16330b@kernel.org> (raw)
In-Reply-To: <CAJuCfpHgMwM7SK-sanGpEyCxCi-T+gDqFJHnV_AMt=S-x5oynw@mail.gmail.com>
On 7/15/26 18:02, Suren Baghdasaryan wrote:
> On Wed, Jul 15, 2026 at 3:10 AM Vlastimil Babka (SUSE)
> <vbabka@kernel.org> wrote:
>>
>> struct kfence_metadata only has obj_exts with CONFIG_MEMCG.
>
> I don't quite understand this statement. obj_exts are allocated when
> either CONFIG_MEMCG or CONFIG_MEM_ALLOC_PROFILING is enabled.
See in mm/kfence/kfence.h
struct kfence_metadata {
...
#ifdef CONFIG_MEMCG
struct slabobj_ext obj_exts;
#endif
...
then in mm/kfence/core.c kfence_init_pool()
#ifdef CONFIG_MEMCG
struct slab *slab = page_slab(page);
slab->obj_exts = (unsigned long)&kfence_metadata_init[i / 2 - 1].obj_exts |
MEMCG_DATA_OBJEXTS;
#endif
So the slab kfence fakes only has this pre-inited obj_exts
with CONFIG_MEMCG.
What happens if we run memalloc profiling without MEMCG and this
fake slab doesn't have a pre-assigned obj_exts? I guess
__alloc_tagging_slab_alloc_hook() will allocate it via
prepare_slab_obj_exts_hook().
But it's something that was done consciously and probably
just accidentally works.
>> If it's
>> enabled, it does also work for allocation profiling, but there's little
>> value recording tags for KFENCE objects.
>
> Unless we are leaking them, right?
Well if there are leaks in a particular callsite, we should see that from all
the allocations that don't end up in kfence (as kfence allocations are rare).
So we are very unlikely to miss a leak due to this.
>> Furthermore it would complicate
>> the upcoming changes, so just skip them in the slab hooks.
>
> Ok, I can understand that. If we do this, we should document that
> kfence objects are no longer tracked.
>
>>
>> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
>> ---
>> mm/slub.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/mm/slub.c b/mm/slub.c
>> index 0337e60db5ac..a4be70d080fb 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -2352,6 +2352,9 @@ __alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags,
>> if (alloc_flags & SLAB_ALLOC_NO_RECURSE)
>> return;
>>
>> + if (is_kfence_address(object))
>> + return;
>> +
>> slab = virt_to_slab(object);
>> obj_exts = prepare_slab_obj_exts_hook(s, slab, flags, alloc_flags, object);
>> /*
>> @@ -2399,6 +2402,9 @@ __alloc_tagging_slab_free_hook(struct kmem_cache *s, struct slab *slab, void **p
>> for (i = 0; i < objects; i++) {
>> unsigned int off = obj_to_index(s, slab, p[i]);
>>
>> + if (is_kfence_address(p[i]))
>> + continue;
>> +
>> alloc_tag_sub(&slab_obj_ext(slab, obj_exts, off)->ref, s->size);
>> }
>> put_slab_obj_exts(obj_exts);
>>
>> --
>> 2.55.0
>>
next prev parent reply other threads:[~2026-07-16 9:11 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 10:10 [PATCH RFC 00/12] mm/slab, alloc_tag: reduce obj_ext memory waste Vlastimil Babka (SUSE)
2026-07-15 10:10 ` [PATCH RFC 01/12] mm/slab: skip kfence objects in allocation profiling Vlastimil Babka (SUSE)
2026-07-15 16:02 ` Suren Baghdasaryan
2026-07-16 9:11 ` Vlastimil Babka (SUSE) [this message]
2026-07-16 15:24 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 02/12] mm/slab: remove objs_per_slab() Vlastimil Babka (SUSE)
2026-07-15 16:13 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 03/12] mm: move struct slabobj_ext to mm/slab.h Vlastimil Babka (SUSE)
2026-07-16 0:56 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 04/12] mm/slab: make slab_obj_ext() determine object index Vlastimil Babka (SUSE)
2026-07-16 1:02 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 05/12] mm/slab: abstract slabobj_ext.objcg access Vlastimil Babka (SUSE)
2026-07-16 1:27 ` Suren Baghdasaryan
2026-07-16 13:58 ` Vlastimil Babka (SUSE)
2026-07-16 15:27 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 06/12] mm/slab: abstract slabobj_ext.ref access Vlastimil Babka (SUSE)
2026-07-16 1:28 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 07/12] mm/slab: replace slab.stride with obj_exts_in_object Vlastimil Babka (SUSE)
2026-07-16 1:44 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 08/12] mm/slab: change struct slabobj_ext to a union Vlastimil Babka (SUSE)
2026-07-16 4:11 ` Suren Baghdasaryan
2026-07-16 14:43 ` Vlastimil Babka (SUSE)
2026-07-16 15:28 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 09/12] mm/slab: introduce slab_obj_ext_has_codetag() Vlastimil Babka (SUSE)
2026-07-16 4:25 ` Suren Baghdasaryan
2026-07-16 14:47 ` Vlastimil Babka (SUSE)
2026-07-15 10:10 ` [PATCH RFC 10/12] mm/slab: reduce slabobj_ext memory with allocation profiling disabled Vlastimil Babka (SUSE)
2026-07-16 4:30 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 11/12] mm/slab: add slab_needs_objcg() helper Vlastimil Babka (SUSE)
2026-07-16 4:36 ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 12/12] mm/slab: stop allocating objcg pointers when unnecessary Vlastimil Babka (SUSE)
2026-07-16 4:46 ` Suren Baghdasaryan
2026-07-16 15:08 ` Vlastimil Babka (SUSE)
2026-07-16 15:32 ` Suren Baghdasaryan
2026-07-15 15:32 ` [PATCH RFC 00/12] mm/slab, alloc_tag: reduce obj_ext memory waste Suren Baghdasaryan
2026-07-16 3:28 ` Harry Yoo
2026-07-16 4:55 ` Suren Baghdasaryan
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=ab9782bf-d3dd-4cb5-ae66-127b3a16330b@kernel.org \
--to=vbabka@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=cl@gentwo.org \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.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