On Tuesday 10 September 2002 02:44, Jamie Lokier wrote:
> Typically, your module's resources are protected by a lock or so.
> cleanup_module() could take this lock, check any private reference
> counts, and (because it has the lock) decide whether to proceed with
> unregistering the module's resources.
Actually, there did turn out to be a problem with the code I showed
yesterday, resulting from the fact that cleanup_module wants to be able to
sleep. Because of this, there is no good way for module.c to protect
module->count from try_inc_mod_count, not without changing the spinlock in
try_inc_mod_count into a semaphore, which isn't nice either, because
try_inc_mod_count is taken under at least one other spinlock in super.c.
There's a simple solution though: examine the module->count under the same
spinlock as try_inc_mod_count, which is what sys_delete_module does. We just
encapsulate that check in a handy wrapper and define it as part of the
try_inc_mod_count interface. At this point the thing is generalized to the
point where the module count isn't used at all by module.c, so the same
interface will also accomodate the still-under-construction magic wait for
quiescent state(), needed for modules that don't fit the mod_count model.
The nice thing is, hardly any work is required to accomplish this, though
it's hard to look at module.c for more than a few seconds without seeing more
things that want cleaning up.
-- 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