On Tuesday 10 September 2002 05:26, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > Locking
> > has been arranged by module.c such that this won't increase during the
> > course of the cleanup_module call. The module exit routine does:
> >
> > if (module->count)
> > return module->count;
> >
> > return clean_up_whatever();
>
> If any code within the module does `MOD_DEC_USE_COUNT; return;', you
> have a race condition.
>
> That's why nowadays you shouldn't see this. The main reference points
> to a module are either function calls from another module (already count
> as references), or a file/filesystem/blockdev/netdevice: these all have
> an `owner' field now, so that the MOD_DEC_USE_COUNT can take place
> outside their modules.
Thanks for telling me this, but I know it. The manner in which the
module use count is protected is completely irrelvant to the code I
showed. The cleanup_module just knows the count is protected and
stable.
> If you do still see MOD_DEC_USE_COUNT in a module, then there's a race
> condition. Some task calls the function which does MOD_DEC_USE_COUNT,
> and some _other_ task calls sys_delete_module(). Lo, the module is
> cleaned up and destroyed by the second task while it's in the small
> window just before `return' in the first task.
>
> Given that, you need to either (a) not call MOD_DEC_USE_COUNT in the
> module, and use the `owner' fields of various structures instead, or (b)
> something quite clever involving a quiescent state and some flags.
>
> Note that (b) is not trivial, as you can't just do
> `wait_for_quiescent_state()' followed by `if (module->count)': it's
> possible that someone may call MOD_INC_USE_COUNT after the quiescent
> state has passed, but before you finish cleaning up.
You promised to find a race or some other deficiency in my code and
you pointed out some other interesting, but incidental fact.
If you look at my code snippet for cleanup_module, you'll see it
doesn't decrement anything, though it could if it wanted to, because
it's called under protection provided by module.c.
The way the module keeps track of its unloadable/not unloadable
state is up to it, which makes sense, n'est-ce pas? Given that
there is no way you can make the MOD_DEC_USE_COUNT concept work
for SCM, for example.
There is in fact no choice other than to bite the bullet and
implement some form of magic_wait_for_quiescent_state(), however
hard that may be, to be used in the cases where some precise
accounting method simply isn't possible. The alternative is to
forbid unloading of some types of modules, and I hope you
realize what kind of criticism that would invite.
Anyway, solutions to the difficulties are known. We are simply
quibbling over whether we should use an obscure interface or a
simple, transparent one.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:20 EST