Re: Possible Bug in "sys_init_module"?

[Keith Owens <kaos@ocs.com.au>]

On Mon, 5 Aug 2002 14:57:07 +1000 (EST), 
Kingsley Cheung <kingsley@aurema.com> wrote:
>Please cc me since I'm not on the mailing list.
>
>Assume that one script invokes modprobe which calls "sys_init_module" 
>first.  The big kernel lock is taken and then plenty of sanity checks 
>done. After dependencies are checked and updated, the "init_module" 
>function of the module is invoked. Now if this function happens to block, 
>the kernel lock is dropped. A call to "sys_init_module" by modprobe in 
>the other script to initialise a second module dependent on the first 
>could then take the big kernel lock, check the dependencies and find them 
>okay, and then have its "init_module" function invoked. And if this 
>second module relies on the first module being properly initialised 
>before it is loaded, this can break. 

This is a trade off between two conflicting requirements.  If a module
fails during initialization then we want the module symbols to debug
the module.  But those same symbols should not be considered valid when
doing insmod.  The query_module() interface does not have the
flexibility to distinguish between the two types of user space query.

In any case the problem is bigger than module symbols.  What happens
when a module_init breaks after registering some functions?  The
functions are registered and can be called, but the module is stuffed.
insmod symbols are just one instance of the wider problem - if a module
fails during init or exit and does not recover then the kernel is in an
unreliable state.  It is broken, you get to keep the pieces.

On my todo list for modutils 2.5 is to invoke init_module() from a
separate task.  That task will be killed by the kernel oops (there is
no way for userspace to recover from oops) but the parent insmod will
detect the failure and say

  init_module() for foo failed.  The kernel is in an unreliable state.