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 <[email protected]> > 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
