On Wed, Jun 12, 2024 at 04:54:49PM +0200, Linus Lüssing wrote:
On Wed, Jun 12, 2024 at 04:39:15PM +0200, Linus Lüssing wrote:
On Wed, Jun 12, 2024 at 07:06:04AM -0700, Paul E. McKenney wrote:
Let me make sure that I understand...
You need rcu_barrier() to wait for any memory passed to kfree_rcu() to actually be freed? If so, please explain why you need this, as in what bad thing happens if the actual kfree() happens later.
(I could imagine something involving OOM avoidance, but I need to hear your code's needs rather than my imaginations.)
Thanx, Paul[...] As far as I understand before calling kmem_cache_destroy() we need to ensure that all previously allocated objects on this kmem-cache were free'd. At least we get this kernel splat (from Slub?) otherwise. I'm not quite sure if any other bad things other than this noise in dmesg would occur though. Other than a [...]
I guess, without knowing the details of RCU and Slub, that at least nothing super serious, like a segfault, can happen when the remaining execution is just a kfree(), which won't need access to batman-adv internal functions anymore.
We are looking into nice ways of solving this, but in the meantime, yes, if you are RCU-freeing slab objects into a slab that is destroyed at module-unload time, you currently need to stick with call_rcu() and rcu_barrier().
We do have some potential solutions to allow use of kfree_rcu() with this sort of slab, but they are still strictly potential.
Apologies for my having failed to foresee this particular trap!
Thanx, Paul