On 7/8/26 9:49 AM, Sebastian Andrzej Siewior wrote: > On 2026-07-07 17:32:10 [+0200], Petr Pavlu wrote: >>> --- a/kernel/module/main.c >>> +++ b/kernel/module/main.c >>> @@ -858,6 +858,9 @@ SYSCALL_DEFINE2(delete_module, const char __user *, >>> name_user, >>> goto out; >>> >>> mutex_unlock(&module_mutex); >>> + >>> + /* Ensure all rcu callbacks issued by the module have completed */ >>> + rcu_barrier(); >>> /* Final destruction now no one is using it. */ >>> if (mod->exit != NULL) >>> mod->exit(); >>> >>> make sense? >> >> This is discussed in Documentation/RCU/rcubarrier.rst and >> Documentation/RCU/Design/Requirements/Requirements.rst. The latter >> contains: > > I am aware of this. It is just not the first time I stumble about this. > But maybe with the AI review these days there won't be a miss. > >> I don't know if the last part about unacceptable latencies is still >> relevant. I haven't done any measurements myself. > > There is a synchronize_rcu() later on. I think I could replace it with a > call_rcu() so we might end up even. I was thinking about about it last > time I was touching modules but somehow I stopped where I stopped. > The question is just, is it worth doing it or is it reasonable to expect > that it is done correctly.
As RCU usage in modules is now more common, I see an argument for the module loader to invoke rcu_barrier() during module unload to make RCU usage easier. In general, module unloading is a rare operation, so even if it becomes somewhat slower, I don't expect it to be a significant issue. One problem is that I'm not sure where the new rcu_barrier() call should be placed. The prototype adds it before calling the module's exit function. Would this actually fit all modules? From a quick look, I can see that various modules call it at different points during their exit. -- Thanks, Petr
