Re: [PATCH RFC 01/12] mm/slab: skip kfence objects in allocation profiling

"Vlastimil Babka (SUSE)" <[email protected]>
Newsgroups org.kernel.vger.cgroups,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 7/15/26 18:02, Suren Baghdasaryan wrote:
> On Wed, Jul 15, 2026 at 3:10 AM Vlastimil Babka (SUSE)
> <[email protected]> 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) <[email protected]>
>> ---
>>  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
>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.