On 7/6/26 11:29 AM, Sebastian Andrzej Siewior wrote: > + MODULE maintainer
+ Paul E. McKenney > > On 2026-07-05 10:57:44 [+0800], Qingfang Deng wrote: >> On 7/4/2026 at 12:32 AM, Breno Leitao wrote: >>> On Fri, Jul 03, 2026 at 03:27:00PM +0800, Qingfang Deng wrote: >>>> AI-review found an issue: >>>> https://sashiko.dev/#/patchset/D9C0245B-608B-4884-8A09-F55BA4A9F948%40doyensec.com >>>> >>>> An rcu_barrier() call is needed at the end of ppp_cleanup(). >>> >>> I was initially unclear why rcu_barrier() would be necessary on a kfree >>> path, >>> but it appears to be required during module unload to ensure that >>> ppp_release_channel_free() completes before the module's struct rcu_head is >>> destroyed. Is that the correct understanding? >> >> It's required to ensure that all ppp_release_channel_free() callback >> complete before the text segment of the module is unloaded. > > So either a rcu_barrier() in ppp's module_exit() callback or a > synchronize_rcu() instead of the call_rcu(). And all this because the > module RCU callbacks pending which can be invoked after the module has > been removed. There is a synchronize_rcu() during module exit but this > is after the module code is gone. > > I'm curious how many modules have a call_rcu() within their code but > don't have anything to enforce its completion before module removal is > complete? Wouldn't something like > > > diff --git a/kernel/module/main.c b/kernel/module/main.c > index 46dd8d25a6058..8eae1ea2d6eb4 100644 > --- 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: | Loadable Modules | ~~~~~~~~~~~~~~~~ | | The Linux kernel has loadable modules, and these modules can also be | unloaded. After a given module has been unloaded, any attempt to call | one of its functions results in a segmentation fault. The module-unload | functions must therefore cancel any delayed calls to loadable-module | functions, for example, any outstanding mod_timer() must be dealt | with via timer_shutdown_sync() or similar. | | Unfortunately, there is no way to cancel an RCU callback; once you | invoke call_rcu(), the callback function is eventually going to be | invoked, unless the system goes down first. Because it is normally | considered socially irresponsible to crash the system in response to a | module unload request, we need some other way to deal with in-flight RCU | callbacks. | | RCU therefore provides rcu_barrier(), which waits until all | in-flight RCU callbacks have been invoked. If a module uses | call_rcu(), its exit function should therefore prevent any future | invocation of call_rcu(), then invoke rcu_barrier(). In theory, | the underlying module-unload code could invoke rcu_barrier() | unconditionally, but in practice this would incur unacceptable | latencies. I don't know if the last part about unacceptable latencies is still relevant. I haven't done any measurements myself. -- Thanks, Petr
