Re: [PATCH slab/for-next-fixes v2 0/3] mm/slab: fix unbounded recursion in free path with memalloc profiling

[Harry Yoo <harry@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1569 bytes --]



On 7/10/26 10:07 PM, Vlastimil Babka (SUSE) wrote:
> On 7/10/26 08:03, Harry Yoo (Oracle) wrote:
>> This is a follow-up fix after the recent discussion [1].
>> See patch 2 for the detailed description on the bug.
>>
>> Based on slab/for-next-fixes (72bb229f916) and will be soon available
>> at git.kernel.org [2].
>>
>> Instead preventing cycles by bumping up the allocation size of obj_exts
>> arrays, it introduces a new kmalloc type called KMALLOC_NO_OBJ_EXT and
>> disallow formation of cycles between kmalloc types when allocating
>> obj_exts arrays. obj_exts arrays of normal kmalloc caches are served
>> from KMALLOC_NO_OBJ_EXT caches (that don't have obj_exts), and all other
>> obj_exts arrays are served from normal kmalloc caches.
> 
> Since we agreed to investigate later whether it makes sense to start
> allocating all obj_ext allocations from the new type, I wonder if for now we
> should not create them at all if they won't be used - if anything to avoid
> polluting slabinfo.

That's fair point!

> AFAIU that means only create them with mem alloc
> profiling is config-enabled and mem_profiling_support == true?

assuming mem_profiling_support == true means not "never"...

> (Or probably also with SLUB_TINY && MEMCG, as nonsensical as it is...)

I'll instead check "is any kmalloc type w/ higher priority than
KMALLOC_CGROUP aliased with KMALLOC_NORMAL?", which would be

IS_ENABLED(CONFIG_MEMCG) &&
(KMALLOC_DMA == KMALLOC_NORMAL || KMALLOC_RECLAIM == KMALLOC_NORMAL),


-- 
Cheers,
Harry / Hyeonggon


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]