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

[Vlastimil Babka (SUSE)]

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. AFAIU that means only create them with mem alloc
profiling is config-enabled and mem_profiling_support == true?
(Or probably also with SLUB_TINY && MEMCG, as nonsensical as it is...)

> I tried to reuse SLAB_ALLOC_NO_RECURSE to make kmalloc_slab() select
> KMALLOC_NO_OBJ_EXT, but it was not great because it does not allow
> sheaves for those caches. So I introduced a new slab alloc flag
> SLAB_ALLOC_NO_OBJ_EXT.
> 
> To avoid huge confusion, I had to decouple "disallowing sheaves"
> semantics from SLAB_NO_OBJ_EXT and introduced SLAB_NO_SHEAVES.
> 
> While this cannot be directly backported to v6.18 and v6.12 due to lack
> of SLAB_ALLOC_* flags and kmalloc_flags(), I don't this will be
> particularily challenging to backport it. Instead of a new slab alloc
> flag, we can use __GFP_NO_OBJ_EXT to select KMALLOC_NO_OBJ_EXT as
> kmalloc caches don't have sheaves in v6.18 anyway.
> 
> [1] https://lore.kernel.org/linux-mm/9a139365-28e6-4f1e-b35b-7f6091e9aa14@xxxxxxxxxx
> 
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/harry/linux.git/log/?h=kmalloc-no-objext-v2r2
> 
> [ "v2r2" because after exposing v2r1 I adjusted some of Vlastimil's
>   feedback and fixed a memory leak due to bootstrapping twice when
>   kmalloc caches are aliased ]
> 
> Signed-off-by: Harry Yoo (Oracle) <harry@xxxxxxxxxx>
> ---
> Changes in v2:
> - Fix a memory leak when kmalloc caches are aliased (patch 1).
>   This is included as part of this series as patch 3 makes it
>   easier to trigger the leak.
> 
> - Fix a warning in MEM_ALLOC_PROFILING_DEBUG by dropping
>   mark_obj_codetag_empty() for obj_exts. Sashiko raised this and
>   I reproduced it and confirmed that the warnings are gone.
>   https://sashiko.dev/#/patchset/20260702-kmalloc-no-objext-v1-0-167175008538%40kernel.org
> 
> - Added R-b from Vlastimil on patch 2, thanks!
> - Adjusted Vlastimil's feedback on RFC v1
> - Link to v1: https://lore.kernel.org/r/20260702-kmalloc-no-objext-v1-0-167175008538@xxxxxxxxxx
> 
> ---
> Harry Yoo (Oracle) (3):
>       mm/slab: fix a memory leak due to bootstrapping sheaves twice
>       mm/slab: decouple SLAB_NO_SHEAVES from SLAB_NO_OBJ_EXT
>       mm/slab: prevent unbounded recursion in free path with new kmalloc type
> 
>  include/linux/slab.h |  16 +++++++-
>  mm/slab.h            |  15 +++++--
>  mm/slab_common.c     |  18 ++++++++-
>  mm/slub.c            | 109 +++++++++++++++++++++------------------------------
>  4 files changed, 88 insertions(+), 70 deletions(-)
> ---
> base-commit: 72bb229f9161a1efcd5df32141b69fcc6ae81a13
> change-id: 20260702-kmalloc-no-objext-2619c1e06083
> 
> Best regards,