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
