Linux cgroups development
 help / color / mirror / Atom feed
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
>>


  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