On 7/8/26 9:49 AM, Sebastian Andrzej Siewior wrote:

On 2026-07-07 17:32:10 [+0200], Petr Pavlu wrote:

quoted

quoted

--- 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.

quoted

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