On Wed, Jun 12, 2024 at 08:38:02PM -0700, Paul E. McKenney wrote: > o Make the current kmem_cache_destroy() asynchronously wait for > all memory to be returned, then complete the destruction. > (This gets rid of a valuable debugging technique because > in normal use, it is a bug to attempt to destroy a kmem_cache > that has objects still allocated.) > > o Make a kmem_cache_destroy_rcu() that asynchronously waits for > all memory to be returned, then completes the destruction. > (This raises the question of what to is it takes a "long time" > for the objects to be freed.) These seem like the best two options. > o Make a kmem_cache_free_barrier() that blocks until all > objects in the specified kmem_cache have been freed. > > o Make a kmem_cache_destroy_wait() that waits for all memory to > be returned, then does the destruction. This is equivalent to: > > kmem_cache_free_barrier(&mycache); > kmem_cache_destroy(&mycache); These also seem fine, but I'm less keen about blocking behavior. Though, along the ideas of kmem_cache_destroy_rcu(), you might also consider renaming this last one to kmem_cache_destroy_rcu_wait/barrier(). This way, it's RCU focused, and you can deal directly with the question of, "how long is too long to block/to memleak?" Specifically what I mean is that we can still claim a memory leak has occurred if one batched kfree_rcu freeing grace period has elapsed since the last call to kmem_cache_destroy_rcu_wait/barrier() or kmem_cache_destroy_rcu(). In that case, you quit blocking, or you quit asynchronously waiting, and then you splat about a memleak like we have now. But then, if that mechanism generally works, we don't really need a new function and we can just go with the first option of making kmem_cache_destroy() asynchronously wait. It'll wait, as you described, but then we adjust the tail of every kfree_rcu batch freeing cycle to check if there are _still_ any old outstanding kmem_cache_destroy() requests. If so, then we can splat and keep the old debugging info we currently have for finding memleaks. Jason
