Does this patch about module loading make sense?

[Alison Schofield]

On Mon, Jun 16, 2025 at 05:30:46PM -0400, Julian LaGattuta wrote:
> Hi,
> I'm new to the linux kernel and have never made a patch. I just made a
> modification, on my own system, to linux that cancels the loading of a
> module if the module crashes during its init call.
> This has the benefit of allowing modules to be unloaded after they
> have crashed in the init, and allow callers of the init_module syscall
> to get a response saying the module crashed.
> 
> Normally, the init call happens in the same thread as whoever wants to
> load the module.
> The way this is implemented is that I moved the init call to a
> separate kthread and I detect if the kthread exited normally. If the
> kthread failed, load_module returns -ECANCELED.
> 
> My questions are:
> Is this a feature worth submitting a patch for?
> Is there a reason this hasn't been done?
> Are there fundamental flaws in my approach?
> Is there other feedback I should have?
> 
> I don't know other people with experience with the linux kernel so
> anyone's feedback would  be helpful.

I suspect you will find (I'm no expert in this area) that crashes
in init() are viewed as bugs and not recoverable errors. Trying
to unload after an init failure has the potential for more trouble
and is avoided.

Kthread usage breaks the synchronous nature of module loading.

Maybe there is some merit in better diagnostic info on the
failure to differentiate between clean error returns and
actual crashes.

I'm actually responding to answer you question with regards to how
you can explore this area further so that you may feel confident
in posting your query or patch to the right mailing list - other
than kernelnewbies:

So,let's get you further oriented to search in the area you are
interested - modules.

Based on what you write, I think you've modified kernel/module/main.c.
So, if that's your area, here's how you uncover more history about
module init behavior.

1) See what's happening lately, or a long time ago, in that file:

kernel/module $ git log --pretty=oneline --abbrev-commit main.c

and then you can use git log and grep for all sorts of key words.
Note that these each have 'Lore' links so that you can see the
discussion that went on before the patch was accepted if you
follow the lore link.

2) Find and search the lore mailing list:

There are a few ways to find the list. My shortest method would be
to look at the latest commit in main.c and jump to the lore link
to see what list it is on.  You can also just look it up in the
MAINTAINERS file - ie kernel/module/ is under 'MODULE SUPPORT'
and has an L: linux-modules at vger.kernel.org
(we'll ignore the other 'L: linux-kernel at vger.kernel.org) for
now since that is the everything in kernel list.

The lore link is: https://lore.kernel.org/linux-modules/

Once you are reading lore you'll see the most common posting by
far is a patch. Even if the change is questionable, folks like 
to think in patches so they submit an RFC so reviewers can see
their intent.

Good luck!

> 
> Sincerely,
> Julian
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies