Re: [syzbot] [mm?] [f2fs?] [exfat?] memory leak in __kfree_rcu_sheaf

[Harry Yoo <harry.yoo@oracle.com>]

On Mon, Mar 09, 2026 at 08:31:03PM +0000, Catalin Marinas wrote:
> On Mon, Mar 09, 2026 at 09:17:32PM +0900, Harry Yoo wrote:
> > On Fri, Mar 06, 2026 at 07:35:01PM +0000, Catalin Marinas wrote:
> > 
> > [...snip...]
> > 
> > > I wonder whether some early kmem_cache_node allocations like the ones in
> > > early_kmem_cache_node_alloc() are not tracked and then kmemleak cannot
> > > find n->barn. I got lost in the slub code, but something like this:
> > 
> > This sounds plausible. Before sheaves, kmem_cache_node just maintained
> > a list of slabs. Because struct page (and struct slab overlaying on it)
> > is not tracked by kmemleak (as Vlastimil pointed out off-list),
> > not calling kmemleak_alloc() for kmem_cache_node was not a problem.
> > 
> > But now it maintains barns and sheaves,
> > and they are tracked by kmemleak...
> 
> We could simply add kmemleak_ignore(), especially as we don't need the
> data in these structures to be scanned. We can assume the slab allocator
> doesn't leak it's own data structures.

Yeah that sounds reasonable to me.

> But I couldn't figure out why
> kmemleak couldn't track down the pointer in the first place and any
> random kmemleak_alloc() I added did not solve it.

Perhaps we're seeing mix of

  - kmem_cache_node not being tracked by kmemleak causes false positives
  - sheaves submitted to call_rcu() cause false positives
  - not calling kmemleak_ignore() on kvfree_rcu'd objects cause
    false positives

So I tried both:

  1) calling kmemleak_ignore() on kfree_rcu'd objects +
     calling kmemleak_ignore() when submitting rcu sheaves to call_rcu() +
     calling kmemleak_unignore() when rcu sheaves are reused  +
     calling kmemleak_alloc() on early kmem_cache_node allocation

     https://lore.kernel.org/linux-mm/aa-1-Y3v3D1hzPvL@hyeyoo

  2) calling kmemleak_ignore() on kfree_rcu'd objects +
     calling kmemleak_ignore() on all sheaves (__alloc_empty_sheaf) +
     calling kmemleak_alloc() on early kmem_cache_node allocation
   
     https://lore.kernel.org/linux-mm/aa_R-6SdHYBBkQX-@hyeyoo

They seem to resolve reports for sheaves and kfree_rcu'd objects.

But yeah, there are still a bunch of leak reports
(hopefully not false positives caused by slab anymore?) 

I notice that some of those objects are freed in a call_rcu() callback.

If submitting to call_rcu() put objects into rcu data structures
that kmemleak is not aware of, how has kmemleak dealt with that?
(perhaps users need to call kmemleak_ignore() before call_rcu()?)

> > > -----------8<-----------------------------------
> > > diff --git a/mm/slub.c b/mm/slub.c
> > > index 0c906fefc31b..401557ff5487 100644
> > > --- a/mm/slub.c
> > > +++ b/mm/slub.c
> > > @@ -7513,6 +7513,7 @@ static void early_kmem_cache_node_alloc(int node)
> > >  	slab->freelist = get_freepointer(kmem_cache_node, n);
> > >  	slab->inuse = 1;
> > >  	kmem_cache_node->node[node] = n;
> > > +	kmemleak_alloc(n, sizeof(*n), 1, GFP_NOWAIT);

By the way, this should have been kmem_cache_node->object_size.
Because... the length of kmem_cache_node.node array is not always
MAX_NUMNODES (yeah, that's confusing).

> > >  	init_kmem_cache_node(n, NULL);
> > >  	inc_slabs_node(kmem_cache_node, node, slab->objects);
> > 
> > But this function is called for kmem_cache_node cache
> > (in kmem_cache_init()), even before kmemleak_init()?
> 
> That's fine, kmemleak starts as enabled by default and tracks early
> allocations in a local mem_pool[] array. kmemleak_init() just
> initialises its kmem_caches for the long run.

Ah, right. I totally missed that. Thanks for the correction!

> > kmem_cache and kmalloc caches should call kmemleak_alloc() when
> > allocating kmem_cache_node structures, but as they are also created
> > before kmemleak_init(), I doubt that's actually doing its job...
> 
> It does. I just added a kmemleak_alloc() in create_kmalloc_cache() and
> kmemleak complained that the object from the kmem_cache_zalloc() is
> already registered. Of course, no stack trace saved for these early
> allocations but it does track them.

Right!

> > > -------------8<----------------------------------------
> > > 
> > > Another thing I noticed, not sure it's related but we should probably
> > > ignore an object once it has been passed to kvfree_call_rcu(), similar
> > > to what we do on the main path in this function. Also see commit
> > > 5f98fd034ca6 ("rcu: kmemleak: Ignore kmemleak false positives when
> > > RCU-freeing objects") when we added this kmemleak_ignore().
> > > 
> > > ---------8<-----------------------------------
> > > diff --git a/mm/slab_common.c b/mm/slab_common.c
> > > index d5a70a831a2a..73f4668d870d 100644
> > > --- a/mm/slab_common.c
> > > +++ b/mm/slab_common.c
> > > @@ -1954,8 +1954,14 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr)
> > >  	if (!head)
> > >  		might_sleep();
> > >  
> > > -	if (!IS_ENABLED(CONFIG_PREEMPT_RT) && kfree_rcu_sheaf(ptr))
> > > +	if (!IS_ENABLED(CONFIG_PREEMPT_RT) && kfree_rcu_sheaf(ptr)) {
> > > +		/*
> > > +		 * The object is now queued for deferred freeing via an RCU
> > > +		 * sheaf. Tell kmemleak to ignore it.
> > > +		 */
> > > +		kmemleak_ignore(ptr);
> > 
> > As Vlastimil pointed out off-list, we need to let kmemleak ignore
> > sheaves when they are submitted to call_rcu() and ideally undo
> > kmemleak_ignore() in __kfree_rcu_sheaf() when they are going to be reused.
> > 
> > But looking at mm/kmemleak.c, undoing kmemleak_ignore() doesn't seem to
> > be a thing.
> 
> If that's needed, something like below:

Thanks, that was helpful!

In addition to that - assuming that OBJECT_NO_SCAN should be cleared
when changing the color from black to white, I made that change when
testing it using syzbot.

> ----------------------8<---------------------------------
> diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst
> index 7d784e03f3f9..da2c849d4735 100644
> --- a/Documentation/dev-tools/kmemleak.rst
> +++ b/Documentation/dev-tools/kmemleak.rst
> @@ -163,6 +163,7 @@ See the include/linux/kmemleak.h header for the functions prototype.
>  - ``kmemleak_not_leak``	 - mark an object as not a leak
>  - ``kmemleak_transient_leak``	 - mark an object as a transient leak
>  - ``kmemleak_ignore``		 - do not scan or report an object as leak
> +- ``kmemleak_unignore``		 - undo a previous kmemleak_ignore()
>  - ``kmemleak_scan_area``	 - add scan areas inside a memory block
>  - ``kmemleak_no_scan``	 - do not scan a memory block
>  - ``kmemleak_erase``		 - erase an old value in a pointer variable
> diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
> index fbd424b2abb1..4eec0560be09 100644
> --- a/include/linux/kmemleak.h
> +++ b/include/linux/kmemleak.h
> @@ -28,6 +28,7 @@ extern void kmemleak_update_trace(const void *ptr) __ref;
>  extern void kmemleak_not_leak(const void *ptr) __ref;
>  extern void kmemleak_transient_leak(const void *ptr) __ref;
>  extern void kmemleak_ignore(const void *ptr) __ref;
> +extern void kmemleak_unignore(const void *ptr, int min_count) __ref;
>  extern void kmemleak_ignore_percpu(const void __percpu *ptr) __ref;
>  extern void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp) __ref;
>  extern void kmemleak_no_scan(const void *ptr) __ref;
> @@ -104,6 +105,10 @@ static inline void kmemleak_ignore_percpu(const void __percpu *ptr)
>  static inline void kmemleak_ignore(const void *ptr)
>  {
>  }
> +
> +static inline void kmemleak_unignore(const void *ptr, int min_count)
> +{
> +}
>  static inline void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp)
>  {
>  }
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index d79acf5c5100..99b7ebd03737 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -1292,6 +1292,24 @@ void __ref kmemleak_ignore(const void *ptr)
>  }
>  EXPORT_SYMBOL(kmemleak_ignore);
>  
> +/**
> + * kmemleak_unignore - undo a previous kmemleak_ignore() on an object
> + * @ptr:	pointer to beginning of the object
> + * @min_count:	minimum number of references the object must have to be
> + *		considered a non-leak (see kmemleak_alloc() for details)
> + *
> + * Calling this function undoes a prior kmemleak_ignore() by restoring the
> + * given min_count, making the object visible to kmemleak again.
> + */
> +void __ref kmemleak_unignore(const void *ptr, int min_count)
> +{
> +	pr_debug("%s(0x%px)\n", __func__, ptr);
> +
> +	if (kmemleak_enabled && ptr && !IS_ERR(ptr))
> +		paint_ptr((unsigned long)ptr, min_count, 0);
> +}
> +EXPORT_SYMBOL(kmemleak_unignore);
> +
>  /**
>   * kmemleak_scan_area - limit the range to be scanned in an allocated object
>   * @ptr:	pointer to beginning or inside the object. This also
> ----------------------8<---------------------------------
> 
> -- 
> Catalin

-- 
Cheers,
Harry / Hyeonggon