Re: [PATCH] slab: allow sheaves for SLAB_NOLEAKTRACE caches

[Catalin Marinas <catalin.marinas@arm.com>]

On Fri, Nov 13, 2026 at 10:05:08AM +0000, sashiko-bot@kernel.org wrote:
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 8369853ddca72..f19e20b6f9a4f 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -2850,6 +2850,13 @@ static struct slab_sheaf *__alloc_empty_sheaf(struct kmem_cache *s, gfp_t gfp,
> >  	if (s->flags & SLAB_KMALLOC)
> >  		alloc_flags |= SLAB_ALLOC_NO_RECURSE;
> >  
> > +	/*
> > +	 * kmemleak allocates its metadata from SLAB_NOLEAKTRACE caches, so
> > +	 * tracking their sheaves would recurse into kmemleak.
> > +	 */
> > +	if (s->flags & SLAB_NOLEAKTRACE)
> > +		alloc_flags |= SLAB_ALLOC_NO_LEAKTRACE;
> > +
> >  	sheaf_size = struct_size(sheaf, objects, capacity);
> >  	sheaf = kmalloc_flags(sheaf_size, gfp | __GFP_ZERO, alloc_flags, NUMA_NO_NODE);
> 
> [Severity: Medium]
> Does SLAB_ALLOC_NO_LEAKTRACE leak into nested sheaf and slabobj_ext
> allocations for the backing normal kmalloc cache?
> 
> When s is a SLAB_NOLEAKTRACE cache (such as kmemleak's object_cache),
> s->flags & SLAB_KMALLOC is false, so __alloc_empty_sheaf() passes
> SLAB_ALLOC_NO_LEAKTRACE to kmalloc_flags() without SLAB_ALLOC_NO_RECURSE.
> If the backing normal kmalloc bucket needs a new empty sheaf in
> alloc_from_pcs() -> __pcs_replace_empty_main() -> alloc_empty_sheaf(),
> that nested sheaf allocation inherits SLAB_ALLOC_NO_LEAKTRACE and is not
> registered with kmemleak.
> 
> Because kmemleak never scans that untracked normal kmalloc sheaf:
> - If the sheaf is later used as pcs->rcu_free in __kfree_rcu_sheaf(),
>   kvfree_call_rcu() returns before kmemleak_ignore(ptr) while freeing is
>   deferred, so kmemleak_scan() misses pcs->rcu_free->objects[] and reports
>   queued objects as false-positive leaks.
> - Any tracked kmalloc sheaf linked between two untracked sheaves on
>   barn->sheaves_full or barn->sheaves_empty is unreachable during
>   kmemleak_scan() and is also reported as a false-positive leak.
> - In slab_post_alloc_hook() -> alloc_tagging_slab_alloc_hook() ->
>   prepare_slab_obj_exts_hook() -> alloc_slab_obj_exts(), the slabobj_ext
>   vector is likewise allocated with SLAB_ALLOC_NO_LEAKTRACE still set,
>   skipping kmemleak registration before calling kmemleak_not_leak(vec).
> 
> Setting SLAB_ALLOC_NO_RECURSE along with SLAB_ALLOC_NO_LEAKTRACE (or
> clearing SLAB_ALLOC_NO_LEAKTRACE before nested allocations) would prevent
> the flag from propagating into the normal kmalloc cache's own metadata.

Sashiko is right here, this could lead to false positives. I don't think
clearing SLAB_ALLOC_NO_LEAKTRACE before nested allocations is correct
since that could reintroduce the original recursion. Adding
SLAB_ALLOC_NO_RECURSE alongside it should fix this.

IIUC, I think we need to include SLAB_NOLEAKTRACE in the
mark_obj_codetag_empty() condition in __free_empty_sheaf(), alongside
SLAB_KMALLOC, if we go with the NO_RECURSE option.

-- 
Catalin