From: Petr Pavlu <petr.pavlu@suse.com>
To: Julian LaGattuta <julian.lagattuta@gmail.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Daniel Gomez <da.gomez@samsung.com>,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] module: enable force unloading of modules that have crashed during init
Date: Tue, 30 Sep 2025 15:16:25 +0200 [thread overview]
Message-ID: <3fc3f7e8-3297-4586-91ca-41f07c8a9418@suse.com> (raw)
In-Reply-To: <CADuX1qJZ1V32d0U4hSOUOzte2KE-k-Hzop0zZd4=7Ap-kS3JzQ@mail.gmail.com>
On 9/25/25 12:16 AM, Julian LaGattuta wrote:
>> 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.
>
> Thank you for your response Petr. The motivation comes from when I
> wanted to replace a crashed module with one which does not crash
> without having to reboot. I looked around and saw some other people
> complain about it on stackoverflow.
Hm, I'm still not sure I understand the use case. If it is about being
able to remove a crashed module when developing it, then I wouldn't
expect rebooting the machine to be much of an issue. If it is on the
other hand about removing it on a production machine, then I think
attempting this can leave the machine in a worse state and not something
we should encourage or support.
>
> I thought that if a module crashed during init, it would be in a no
> better position compared to if it were forcefully removed.
> Therefore, there is no reason why this shouldn't be an option as it
> couldn't make the problem worse.
A module can be halfway through its initialization when it crashes. It
may have already registered with various parts of the kernel and
I believe that removing the module from under the kernel's control could
result in even more problems.
The current support for forcefully removing a module overrides the
kernel's tracking of module references. This option was originally
introduced by "[PATCH] Forced module unload" [1]. As far as I can see,
it was related to the module loader rework at that time in "[PATCH]
In-kernel Module Loader" [2]. This rework provided raceless
loading/unloading and marked several MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT
interfaces as obsolete and unsafe. Since some modules still used the old
racy interfaces, it seems the forced removal option was added to make it
possible to remove such modules.
However, this issue should have been fixed a long time ago, so I wonder
if even the current CONFIG_MODULE_FORCE_UNLOAD support is useful.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux-fullhistory.git/commit/?id=d0f8c9a4c2c9d93463d157248c73028670e80a97
[2] https://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux-fullhistory.git/commit/?id=4c877b08daf4b463c144cbd2748ed1659931a0dd
--
Thanks,
Petr
next prev parent reply other threads:[~2025-09-30 13:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 20:11 [PATCH 0/6] module: enable force unloading of modules that have crashed during init julian-lagattuta
2025-09-18 20:11 ` [PATCH 1/6] module: store init_pid and idempotent in module julian-lagattuta
2025-09-18 20:11 ` [PATCH 2/6] module: detect if init crashed and unload julian-lagattuta
2025-09-18 20:11 ` [PATCH 3/6] module: move freeinit allocation to avoid memory leak julian-lagattuta
2025-09-18 20:11 ` [PATCH 4/6] module: move idempotent allocation to heap julian-lagattuta
2025-09-18 20:11 ` [PATCH 5/6] module: store and complete idempotent upon force unloading julian-lagattuta
2025-09-18 20:11 ` [PATCH 6/6] module: comment describing new codepath julian-lagattuta
2025-09-23 7:21 ` [PATCH 0/6] module: enable force unloading of modules that have crashed during init Petr Pavlu
2025-09-24 22:16 ` Julian LaGattuta
2025-09-30 13:16 ` Petr Pavlu [this message]
2025-09-30 15:51 ` Julian LaGattuta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3fc3f7e8-3297-4586-91ca-41f07c8a9418@suse.com \
--to=petr.pavlu@suse.com \
--cc=da.gomez@samsung.com \
--cc=julian.lagattuta@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=samitolvanen@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox