Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: Question about pseudo filesystems | Date | Tue, 10 Sep 2002 11:15:54 +0200 |
| |
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/
| |