Module Observations

[Srivatsa Vaddagiri]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/