linux-kernel - Re: module: Ensure a module's state is set accordingly during module coming cleanup code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.1611161635330.12580@pobox.suse.cz>
Date:   Wed, 16 Nov 2016 16:49:31 +0100 (CET)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Jessica Yu <jeyu@...hat.com>
cc:     Rusty Russell <rusty@...tcorp.com.au>,
        Aaron Tomlin <atomlin@...hat.com>,
        linux-kernel@...r.kernel.org, rostedt@...dmis.org
Subject: Re: module: Ensure a module's state is set accordingly during module
 coming cleanup code

On Wed, 9 Nov 2016, Jessica Yu wrote:

> +++ Rusty Russell [26/10/16 11:24 +1030]:
> > Aaron Tomlin <atomlin@...hat.com> writes:
> > > In load_module() in the event of an error, for e.g. unknown module
> > > parameter(s) specified we go to perform some module coming clean up
> > > operations. At this point the module is still in a "formed" state
> > > when it is actually going away.
> > > 
> > > This patch updates the module's state accordingly to ensure anyone on the
> > > module_notify_list waiting for a module going away notification will be
> > > notified accordingly.
> > 
> > I recall a similar proposal before.
> > 
> > I've audited all the subscribers to check they didn't look at
> > mod->state; they seem OK.
> > 
> > We actually do this in the init-failed path, so this should be OK.
> 
> We did discuss a similar proposal before:
> 
>    https://lkml.kernel.org/r/87a8m7ko6j.fsf@rustcorp.com.au
> 
> The complaint back then was that we need to be in the COMING state for
> strong_try_module_get() to fail. But it will also correctly fail for GOING
> modules in the module_is_live() check in the subsequent call to
> try_module_get(), so I believe we are still OK here.

FWIW, I looked and this is true. Even the error -ENOENT could be better in 
this case than -EBUSY (since the module is going away).

Reviewed-by: Miroslav Benes <mbenes@...e.cz>

for the patch, if you want it.

Anyway, the comment above strong_try_module_get() is not true for almost 9 
nine years. So how about something like:

-->8--

>From 872e11394fdaba8fb9a333e114dc92273d2d1bf5 Mon Sep 17 00:00:00 2001
From: Miroslav Benes <mbenes@...e.cz>
Date: Wed, 16 Nov 2016 16:45:48 +0100
Subject: [PATCH] module: Fix a comment above strong_try_module_get()

The comment above strong_try_module_get() function is not true anymore.
Return values changed with commit c9a3ba55bb5d ("module: wait for
dependent modules doing init.").

Signed-off-by: Miroslav Benes <mbenes@...e.cz>
---
 kernel/module.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index f57dd63186e6..67160ca8110e 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -313,8 +313,9 @@ struct load_info {
 	} index;
 };
 
-/* We require a truly strong try_module_get(): 0 means failure due to
-   ongoing or failed initialization etc. */
+/* We require a truly strong try_module_get(): 0 means success.
+ * Otherwise an error is returned due to ongoing or failed
+ * initialization etc. */
 static inline int strong_try_module_get(struct module *mod)
 {
 	BUG_ON(mod && mod->state == MODULE_STATE_UNFORMED);
-- 
2.10.2