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

From: Jessica Yu
Date: Wed Nov 23 2016 - 18:42:04 EST


+++ Miroslav Benes [16/11/16 16:49 +0100]:
On Wed, 9 Nov 2016, Jessica Yu wrote:

+++ Rusty Russell [26/10/16 11:24 +1030]:
> Aaron Tomlin <atomlin@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx

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@xxxxxxx>

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@xxxxxxx>
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@xxxxxxx>

Thanks Miroslav, that comment was confusing and needed updating. I've
queued this on top of the other patches.

Jessica