On Wed, Dec 01, 2021 at 10:24:15AM +0100, Uladzislau Rezki wrote: > On Tue, Nov 30, 2021 at 12:04:19PM +0100, Sebastian Andrzej Siewior wrote: > > 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 :) > > > Indeed that error path sequence is terrible. I will double check if that > synchronize_rcu() + kfree() is related to any RCU protection and freeing. > > If it is not i will drop this patch. > > OK, that kfree has nothing to do with RCU protection: <snip> commit 6526c534b2677ca601b7b92851437feb041d02a1 Author: Rusty Russell <rusty@xxxxxxxxxxxxxxx> Date: Thu Aug 5 12:59:10 2010 -0600 module: move module args strndup_user to just before use Instead of copying and allocating the args and storing it in load_info, we can just allocate them right before we need them. Signed-off-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx> <snip> so, i will drop my patch, since the intention is not to free a ptr after a grace period. Thank you for the review! -- Vlad Rezki