On 2021-11-30 11:39:09 [+0100], Miroslav Benes wrote: > > --- a/kernel/module.c > > +++ b/kernel/module.c > > @@ -4150,8 +4150,7 @@ static int load_module(struct load_info *info, const char __user *uargs, > > ddebug_cleanup: > > ftrace_release_mod(mod); > > dynamic_debug_remove(mod, info->debug); > > - synchronize_rcu(); > > - kfree(mod->args); > > + kvfree_rcu(mod->args); > > free_arch_cleanup: > > cfi_cleanup(mod); > > module_arch_cleanup(mod); > > hm, if I am not missing something, synchronize_rcu() is not really > connected to kfree(mod->args) there. synchronize_rcu() was added a long > time ago when kernel/module.c removed stop_machine() from the code and > replaced it with RCU to protect (at least?) mod->list. You can find > list_del_rcu(&mod->list) a couple of lines below. so instead synchronize_rcu() + kfree() you could do call_rcu(&mod->args->rcu, kfree()) but since you have no RCU-head around in args you wait for the grace period and then invoke kfree. kvfree_rcu() is somehow like call_rcu() + kfree() but without the needed RCU-head. So you avoid waiting for the grace period but mod->args is freed later, after as expected. > And yes, one could ask how this all works. The error/cleanup sequence in > load_module() is a giant mess... well, load_module() is a mess too, but > the error path is really not nice. Well, spring is coming :) > Miroslav Sebastian