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
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
