From: Jessica Yu <jeyu@kernel.org>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: module: treat exit sections the same as init sections when !CONFIG_MODULE_UNLOAD
Date: Fri, 7 May 2021 14:48:42 +0200 [thread overview]
Message-ID: <YJU3KrZzSRYNH6Zt@gunter> (raw)
In-Reply-To: <20210507123054.GD1336@shell.armlinux.org.uk>
+++ Russell King - ARM Linux admin [07/05/21 13:30 +0100]:
>On Fri, May 07, 2021 at 02:13:22PM +0200, Jessica Yu wrote:
>> Dynamic code patching (alternatives, jump_label and static_call) can
>> have sites in __exit code, even if __exit is never executed. Therefore
>> __exit must be present at runtime, at least for as long as __init code is.
>...
>> Previously, the module loader never loaded the exit sections in the first
>> place when CONFIG_MODULE_UNLOAD=n. Commit 33121347fb1c ("module: treat exit
>> sections the same as init sections when !CONFIG_MODULE_UNLOAD") addressed
>> the issue by having the module loader load the exit sections and then making
>> __exit identify as __init for !MODULE_UNLOAD. Then, since they are treated
>> like init sections, they will be also discarded after init.
>>
>> That commit satisfied the above requirements for jump_labels and
>> static_calls by modifying the checks in the core module_init_section()
>> function in kernel/module.c to include exit sections. However, ARM
>> overrides these and implements their own module_{init,exit}_section()
>> functions. Add a similar check for exit sections to ARM's
>> module_init_section() function so that all arches are on the same page.
>
>Shouldn't the module core code itself be doing:
>
> module_init_section(name) || module_exit_section(name)
>
>itself when CONFIG_MODULE_UNLOAD is not set, rather than pushing this
>logic down into every module_init_section() implementation?
Yeah, that sounds better. Originally, I had wanted to keep the #ifndef
in one place to keep the churn to a minimum.
But seeing that we have to patch up ARM too, it's probably the less
ugly option now. Let me cook up an alternative patch and resend.
Thanks,
Jessica
prev parent reply other threads:[~2021-05-07 12:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 12:13 Jessica Yu
2021-05-07 12:30 ` Russell King - ARM Linux admin
2021-05-07 12:48 ` Jessica Yu [this message]
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=YJU3KrZzSRYNH6Zt@gunter \
--to=jeyu@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=peterz@infradead.org \
/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®