Re: module: Ensure a module's state is set accordingly during module coming cleanup code
From: Miroslav Benes
Date: Wed Nov 16 2016 - 10:51:02 EST
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:
> 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: