On 6/16/26 09:55, Vlastimil Babka (SUSE) wrote: > On 6/15/26 13:05, Harry Yoo (Oracle) wrote: > Also maybe there could be a wrapper kfree_maybe_nolock() (~better name?) > That means "I want to kfree safely in kfree_nolock() context something that > MIGHT have been kmalloc()" > And maybe depending on the debugging options that make kmalloc() -> > kfree_nolock() incompatible, if those are not enabled, it wouldn't have to > defer, but proceed normally?
Or just make kfree_nolock() handle all (non-large) kmalloc() objects. Seems the blockers are only kmemleak and kfence. Kmemleak is a debugging option not for production so if it's enabled, just defer free everything. KFENCE is a production option, but we could just defer_free for is_kfence_address() and that will be rare.
