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/