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.