Messages in this thread |  | | Date | Tue, 10 Sep 2002 04:26:22 +0100 | From | Jamie Lokier <> | Subject | Re: Question about pseudo filesystems |
| |
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/
|  |