[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.21.2111301132220.3922@pobox.suse.cz>
Date: Tue, 30 Nov 2021 11:39:09 +0100 (CET)
From: Miroslav Benes <mbenes@...e.cz>
To: "Uladzislau Rezki (Sony)" <urezki@...il.com>
cc: LKML <linux-kernel@...r.kernel.org>, RCU <rcu@...r.kernel.org>,
"Paul E . McKenney" <paulmck@...nel.org>,
Michal Hocko <mhocko@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Daniel Axtens <dja@...ens.net>,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <neeraju@...eaurora.org>,
Joel Fernandes <joel@...lfernandes.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Theodore Y . Ts'o" <tytso@....edu>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Oleksiy Avramchenko <oleksiy.avramchenko@...ymobile.com>,
Luis Chamberlain <mcgrof@...nel.org>, jeyu@...nel.org
Subject: Re: [PATCH 8/9] module: Switch to kvfree_rcu() API
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@...nel.org>
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@...il.com>
> ---
> 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
Powered by blists - more mailing lists