Hi, On Wed, 24 Nov 2021, Uladzislau Rezki (Sony) wrote: > Instead of invoking a synchronize_rcu() to free a pointer > after a grace period we can directly make use of new API > that does the same but in more efficient way. > > CC: Luis Chamberlain <mcgrof@xxxxxxxxxx> > Signed-off-by: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx> > --- > kernel/module.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/kernel/module.c b/kernel/module.c > index 84a9141a5e15..f404f0c9f385 100644 > --- 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. 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. Miroslav
