From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Mike Rapoport <rppt@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jinjie Ruan <ruanjinjie@huawei.com>,
linux-kernel@vger.kernel.org,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Liu Shixin <liushixin2@huawei.com>
Subject: Re: [PATCH] static_call: Handle module init failure correctly in static_call_del_module()
Date: Fri, 8 Nov 2024 09:12:03 +0100 [thread overview]
Message-ID: <8bd5e396-7583-435e-bafc-7d092a31f4ff@csgroup.eu> (raw)
In-Reply-To: <ZvJomuNWjtHYDcsW@kernel.org>
Hi Luis,
Le 24/09/2024 à 09:22, Mike Rapoport a écrit :
> On Thu, Sep 19, 2024 at 02:53:34AM -0700, Luis Chamberlain wrote:
>> On Fri, Sep 06, 2024 at 04:24:56PM -0700, Luis Chamberlain wrote:
>>> On Thu, Sep 05, 2024 at 11:44:00AM +0200, Thomas Gleixner wrote:
>>>> Now you at least provided the information that the missing cleanup in
>>>> the init() function is not the problem. So the obvious place to look is
>>>> in the module core code whether there is a failure path _after_
>>>> module->init() returned success.
>>>>
>>>> do_init_module()
>>>> ret = do_one_initcall(mod->init);
>>>> ...
>>>> ret = module_enable_rodata_ro(mod, true);
>>>> if (ret)
>>>> goto fail_mutex_unlock;
>>>>
>>>> and that error path does _not_ invoke module->exit(), which is obviously
>>>> not correct. Luis?
>>>
>>> You're spot on this needs fixing.
>>
>> Christophe, this is a regression caused by the second hunk of your commit
>> d1909c0221739 ("module: Don't ignore errors from set_memory_XX()") on v6.9.
>> Sadly there are a few issues with trying to get to call mod->exit():
>>
>> - We should try try_stop_module() and that can fail
>> - source_list may not be empty and that would block removal
>> - mod->exit may not exist
>>
>> I'm wondering if instead we should try to do the module_enable_rodata_ro()
>> before the init, but that requires a bit more careful evaluation...
>
> There is ro_after_init section, we can't really make it RO before ->init()
>
Surprisingly I never received Luis's email allthough I got this answer
from Mike that I overlooked.
So coming back here from
https://lore.kernel.org/all/ZyQhbHxDTRXTJgIx@bombadil.infradead.org/
As far as I understand, indeed once init is called it is too late to
fail, right ? Especially when the module has no exit() path or when
CONFIG_MODULE_UNLOAD is not built in.
So the only thing we can do then is a big fat warning telling
set_memory_ro() on ro_after_init memory has failed ?
Maybe we should try and change it to RO then back to RW before calling
init, to be on a safer side hopping that if change to RO works once it
will work twice ?
Christophe
next prev parent reply other threads:[~2024-11-08 8:12 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-15 8:21 [PATCH] static_call: Fix a wild-memory-access bug " Jinjie Ruan
2023-09-15 9:01 ` Peter Zijlstra
2024-09-02 12:01 ` Jinjie Ruan
2024-09-02 12:06 ` Christophe Leroy
2024-09-02 12:07 ` Jinjie Ruan
2024-09-02 12:14 ` Christophe Leroy
2024-09-03 20:01 ` Thomas Gleixner
2024-09-03 22:58 ` [PATCH] static_call: Handle module init failure correctly " Thomas Gleixner
2024-09-04 3:32 ` Jinjie Ruan
2024-09-04 7:08 ` Thomas Gleixner
2024-09-04 8:00 ` Thomas Gleixner
2024-09-04 8:17 ` Peter Zijlstra
2024-09-04 9:08 ` [PATCH] static_call: Replace pointless WARN_ON() in static_call_module_notify() Thomas Gleixner
2024-09-06 14:41 ` [tip: locking/urgent] " tip-bot2 for Thomas Gleixner
2024-09-04 8:03 ` [PATCH] static_call: Handle module init failure correctly in static_call_del_module() Jinjie Ruan
2024-09-04 8:51 ` Thomas Gleixner
2024-09-04 9:50 ` Jinjie Ruan
2024-09-05 3:34 ` Jinjie Ruan
2024-09-05 9:44 ` Thomas Gleixner
2024-09-06 23:24 ` Luis Chamberlain
2024-09-19 9:53 ` Luis Chamberlain
2024-09-24 7:22 ` Mike Rapoport
2024-11-08 8:12 ` Christophe Leroy [this message]
2024-11-08 15:49 ` Luis Chamberlain
2024-11-08 16:09 ` Daniel Gomez
2024-11-08 16:22 ` Daniel Gomez
2024-09-04 9:09 ` [PATCH v2] " Thomas Gleixner
2024-09-04 9:19 ` Jinjie Ruan
2024-09-06 14:41 ` [tip: locking/urgent] " tip-bot2 for Thomas Gleixner
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=8bd5e396-7583-435e-bafc-7d092a31f4ff@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liushixin2@huawei.com \
--cc=mcgrof@kernel.org \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®