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.
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.
-- Jamie
ps. I'm not sure what "SCM" means, so can't comment on that.
-
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