Re: [PATCH RFC 3/5] mm/slab, kmemleak: handle kmemleak freeing in kfree_nolock()

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

On Fri, Aug 07, 2026 at 03:50:29PM +0200, Vlastimil Babka (SUSE) wrote:
> Kmemleak handling is one of the reasons why kfree_nolock() cannot
> currently handle kmalloc() objects, because calling kmemleak_free()
> would involve spinning on its internal raw spinlocks.
> 
> Kmemleak is a debugging mechanism so we could simply defer all
> kfree_nolock() to irq_work if it's enabled, and eat the extra cost. But
> that would be unnecessary pessimistic. We expect kfree_nolock() will be
> still mostly called on objects from kmalloc_nolock() that are not
> registered in kmemleak so they still don't need any deferred freeing.
> 
> Thus introduce kmemleak_may_need_free() that can check if the object is
> registered. This is done using __lookup_object() performed under a
> raw_spin_trylock_irqsave(), which is safe to attempt from kfree_nolock()
> (except from a NMI on a !CONFIG_SMP system). When that trylock fails or
> can't be attempted, we however must assume the object might be
> registered, and defer the freeing.

The only risk is during kmemleak scanning when kmemleak_lock is
repeatedly held by scan_block() even for minutes. There may be some
timing where most kfree_nolock() deferred during such scanning. Not sure
it matters much though, unless the kfree_nolock() use becomes widely
spread. If it becomes problematic, we could add a new RCU-protected hash
that's searchable for this specific case (we can't remove the rbtree as
we need interval searching in general).

Otherwise the kmemleak changes look ok to me.

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

>  void kfree_nolock(const void *object)
>  {
> @@ -6844,9 +6848,23 @@ void kfree_nolock(const void *object)
>  	 */
>  	kasan_slab_free(s, x, false, false, /* skip quarantine */true);

Not related to kmemleak but I noticed this call here: if we relax
kfree_nolock() for any slab objects, would the above poison
SLAB_TYPESAFE_BY_RCU objects while they are still in use? I guess we
should not allow such slabs on this path.

Sashiko had some comments as well, I haven't gone through them but it
also mentioned SLAB_TYPESAFE_BY_RCU on another patch.

-- 
Catalin