Re: [PATCH V2] mm/slab: avoid allocating slabobj_ext array from its own slab

[Vlastimil Babka <vbabka@suse.cz>]

On 1/26/26 14:03, Harry Yoo wrote:
> On Mon, Jan 26, 2026 at 09:57:14PM +0900, Harry Yoo wrote:
>> When allocating slabobj_ext array in alloc_slab_obj_exts(), the array
>> can be allocated from the same slab we're allocating the array for.
>> This led to obj_exts_in_slab() incorrectly returning true [1],
>> although the array is not allocated from wasted space of the slab.
>> 
>> Vlastimil Babka observed that this problem should be fixed even when
>> ignoring its incompatibility with obj_exts_in_slab(), because it creates
>> slabs that are never freed as there is always at least one allocated
>> object.
>> 
>> To avoid this, use the next kmalloc size or large kmalloc when
>> the array can be allocated from the same cache we're allocating
>> the array for.
>> 
>> In case of random kmalloc caches, there are multiple kmalloc caches
>> for the same size and the cache is selected based on the caller address.
>> Because it is fragile to ensure the same caller address is passed to
>> kmalloc_slab(), kmalloc_noprof(), and kmalloc_node_noprof(), bump the
>> size to (s->object_size + 1) when the sizes are equal, instead of
>> directly comparing the kmem_cache pointers.
>> 
>> Note that this doesn't happen when memory allocation profiling is
>> disabled, as when the allocation of the array is triggered by memory
>> cgroup (KMALLOC_CGROUP), the array is allocated from KMALLOC_NORMAL.
>> 
>> Reported-by: kernel test robot <oliver.sang@intel.com>
>> Closes: https://lore.kernel.org/oe-lkp/202601231457.f7b31e09-lkp@intel.com [1]
>> Cc: stable@vger.kernel.org
>> Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths")
>> Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
>> ---
>> 
>> V1 -> V2:
>> - Simplified implementation based on Vlastimil's comment
>> - added virt_to_slab() != NULL check before dereferencing it - because
>>   (in theory) it may be allocated via large kmalloc.
>> 
>>  mm/slub.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++-------
>>  1 file changed, 53 insertions(+), 7 deletions(-)
>> 
>> diff --git a/mm/slub.c b/mm/slub.c
>> index f21b2f0c6f5a..5b4a3b9b7826 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -2095,6 +2095,49 @@ static inline void init_slab_obj_exts(struct slab *slab)
>>  	slab->obj_exts = 0;
>>  }
>>  
>> +/*
>> + * 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 cache 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
>> + * may 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;
> 
> Hmm maybe we don't need this as there's !is_kmalloc_normal(s) check,
> but this allows optimizing out the checks below when
> CONFIG_MEM_ALLOC_PROFILING is not enabled.
> 
> So probably worth keeping it.

Right.

Thanks, added to slab/for-next as the first commit of the obj_metadata branch.