Running a module that encounters a fatal error during the initcall leaves
the module in a state where it cannot be forcefully unloaded since it is 
"being used" despite there being no reason it couldn't be unloaded. 
This means that unloading the crashed module requires rebooting.

This patch allows modules that have crashed during initialization to be
forcefully unloaded with CONFIG_MODULE_FORCE_UNLOAD enabled.


Here are the costs:
 - 2 extra pointers stored in struct module (if CONFIG_MODULE_FORCE_UNLOAD is enabled)
 - struct idempotent is allocated on heap instead of stack (regardless of config)
 
I had to make a design decision for cases where another (f)init_module is
waiting for the crashed module to finish and delete_module is called on it.

Here is an example of the behavior my patch causes:
> insmod crash.ko # insmod calls finit_module and crash.ko runs 0/0 in init
Segmentation Fault
> insmod crash.ko & # insmod will hang forever since it waits for cash.ko init to finish
> rmmod -f crash
[1]+  Exit 1                  insmod crash.ko
insmod: ERROR: could not insert module crash.ko: Device or resource busy

Here, anyone waiting for init to finish will receive -EBUSY upon removal. 
This is true for finit_module and init_module syscalls.
I chose -EBUSY since it means I don't need to modify module_patient_check_exists.
error -ECANCELED might work better

P.S. This is my first patch so I'm new to this.

Signed-off-by: julian-lagattuta <julian.lagattuta@gmail.com>
---
julian-lagattuta (6):
  module: store init_pid and idempotent in module
  module: detect if init crashed and unload
  module: move freeinit allocation to avoid memory leak
  module: move idempotent allocation to heap
  module: store and complete idempotent upon force unloading
  module: comment to describe a new codepath

 include/linux/module.h   |   4 ++
 kernel/module/internal.h |   3 ++
 kernel/module/main.c     | 112 +++++++++++++++++++++++++++++----------
 3 files changed, 92 insertions(+), 27 deletions(-)

-- 
2.45.2

On 9/18/25 10:11 PM, julian-lagattuta wrote:
> Running a module that encounters a fatal error during the initcall leaves
> the module in a state where it cannot be forcefully unloaded since it is 
> "being used" despite there being no reason it couldn't be unloaded. 
> This means that unloading the crashed module requires rebooting.
> 
> This patch allows modules that have crashed during initialization to be
> forcefully unloaded with CONFIG_MODULE_FORCE_UNLOAD enabled.

Could you please explain the motivation for doing this in more detail?

I think we shouldn't attempt to do anything clever with modules that
crashed during initialization. Such a module can already leave the
system in an unstable state and trying to recover can cause even more
problems. For instance, I don't see how it is safe to call the module's
exit function.

-- 
Thanks,
Petr