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

[Shakeel Butt]

On Fri, Jul 17, 2026 at 09:16:19AM +0800, Hao Ge wrote:
> On 2026/7/17 03:37, Shakeel Butt wrote:
> > On Mon, Jul 13, 2026 at 11:28:48PM +0900, Harry Yoo (Oracle) wrote:
> > > This is a follow-up fix after the recent discussion [1].
> > > See patch 4 for the detailed description on the bug.
> > > 
> > > Based on slab/for-next-fixes (af9ea231c0b45) and is 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.
> > > 
> > > 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-v3r1
> > > 
> > > To: Vlastimil Babka <vbabka@xxxxxxxxxx>
> > > To: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> > > To: Hao Li <hao.li@xxxxxxxxx>
> > > To: Christoph Lameter <cl@xxxxxxxxxx>
> > > To: David Rientjes <rientjes@xxxxxxxxxx>
> > > To: Roman Gushchin <roman.gushchin@xxxxxxxxx>
> > > To: Suren Baghdasaryan <surenb@xxxxxxxxxx>
> > > To: Hao Ge <hao.ge@xxxxxxxxx>
> > > To: Kees Cook <kees@xxxxxxxxxx>
> > > To: Pedro Falcato <pfalcato@xxxxxxx>
> > > To: Shakeel Butt <shakeel.butt@xxxxxxxxx>
> > > To: Danielle Constantino <dcostantino@xxxxxxxx>
> > > To: Liam R. Howlett <liam@xxxxxxxxxxxxx>
> > > Cc: linux-mm@xxxxxxxxx
> > > Cc: linux-kernel@xxxxxxxxxxxxxxx
> > > Signed-off-by: Harry Yoo (Oracle) <harry@xxxxxxxxxx>
> > I tested next-20260716 which has this series against next-20260707 which does
> > not have the fix. The reproducer were able to trigger the leak/recursion on
> > next-20260707 but not on next-20260716. So, you can add:
> 
> 
> Hi Shakeel
> 
> 
> It seems you have a consistent stable reproduction method or test script.
> 
> Would you mind sharing it if possible?  I'm sorry if this was provided
> earlier and I overlooked it.
> 
> I'd like to thoroughly investigate and learn about this problem.
> 
> Thank you very much.
> 
>