On Tue, 19 Jun 2001 09:59:25 -0500,
Dean Roehrich <roehrich@xxxxxxx> wrote:
>It's not yet clear to me that there was a bug :) If the person who reported
>the unload problem was using dmapi and didn't clean up their sessions then I
>cannot let them unload the module--it wouldn't matter where we bumped and
>dropped reference counts. Is that person still following this thread?
The problem is that MOD_DEC_USE_COUNT is only called from
dmapi_uninit(). That is called from exit_xfs_fs() in
fs/xfs/linux/xfs_super.c. exit_xfs_fs() is declared as module_exit.
module_exit routines are only called when the module is being removed,
i.e. after the use count has already gone to zero.
So MOD_DEC_USE_COUNT is only issued when the module is being removed
but the module cannot be removed until MOD_DEC_USE_COUNT has been
issued. Catch 22.
Looking at dmapi_uninit, it calls dm_uninit() which checks if dmapi can
be removed. Modules support another mechanism besides use counts, a
module can set its own 'can_unload' function in struct module
__this_module. When can_unload is set, the use count is ignored,
instead that function is called to see if the module can be unloaded.
The only problem is that modules with a can_unload function have a use
count of -1 which confuses a lot of users, even though it is in the l-k
FAQ. I would prefer use counts to be set instead of using can_unload.
BTW, if dm_uninit fails then dmapi_dev is not unregistered. But the
module will still be unloaded, module_exit routines are not allowed to
fail.
|