Messages in this thread Patch in this message | | | Date | Fri, 2 Jan 2004 18:55:09 +0530 | From | Srivatsa Vaddagiri <> | Subject | Module Observations |
| |
Hi, I was going thr' module code and made some observations:
1. sys_init_module drops the module_mutex semaphore before calling mod->init() function and later reacquires it. After reacquiring, it marks the module state as MODULE_STATE_LIVE.
In the window when mod->init() function is running, isn't it possible that sys_delete_module (running on some other CPU and trying to remove the _same_ module) acquires the module_mutex sem and marks the module state as MODULE_STATE_GOING?
Shouldn't sys_init_module check for that possibility when it reacquires the semaphore after calling mod->init function?
--- module.c.org Fri Jan 2 18:37:54 2004 +++ module.c Fri Jan 2 18:38:57 2004 @@ -1750,7 +1750,8 @@
/* Now it's a first class citizen! */ down(&module_mutex); - mod->state = MODULE_STATE_LIVE; + if (likely(mod->state != MODULE_STATE_GOING)) + mod->state = MODULE_STATE_LIVE; /* Drop initial reference. */ module_put(mod); module_free(mod, mod->module_init);
This off-course means that you are trying to insmod and rmmod the same module simultaneously from different CPUs and hence may not be practical.
2. try_module_get() and module_put()
try_module_get increments the local cpu's ref count for the module and module_put decrements it.
Is it required that the caller call both these functions from the same CPU? Otherwise, the total refcount for the module will be non-zero!
--
Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 - 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/
| |