Re: [PATCH 8/9] module: Switch to kvfree_rcu() API

[Miroslav Benes]

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