patches.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev, Adam Johnston <adam.johnston@arm.com>,
	James Morse <james.morse@arm.com>,
	Luis Chamberlain <mcgrof@kernel.org>
Subject: [PATCH 5.15 2/9] module: Expose module_init_layout_section()
Date: Thu, 31 Aug 2023 13:10:10 +0200	[thread overview]
Message-ID: <20230831110830.160595628@linuxfoundation.org> (raw)
In-Reply-To: <20230831110830.039135096@linuxfoundation.org>

5.15-stable review patch.  If anyone has any objections, please let me know.

------------------

From: James Morse <james.morse@arm.com>

commit 2abcc4b5a64a65a2d2287ba0be5c2871c1552416 upstream.

module_init_layout_section() choses whether the core module loader
considers a section as init or not. This affects the placement of the
exit section when module unloading is disabled. This code will never run,
so it can be free()d once the module has been initialised.

arm and arm64 need to count the number of PLTs they need before applying
relocations based on the section name. The init PLTs are stored separately
so they can be free()d. arm and arm64 both use within_module_init() to
decide which list of PLTs to use when applying the relocation.

Because within_module_init()'s behaviour changes when module unloading
is disabled, both architecture would need to take this into account when
counting the PLTs.

Today neither architecture does this, meaning when module unloading is
disabled there are insufficient PLTs in the init section to load some
modules, resulting in warnings:
| WARNING: CPU: 2 PID: 51 at arch/arm64/kernel/module-plts.c:99 module_emit_plt_entry+0x184/0x1cc
| Modules linked in: crct10dif_common
| CPU: 2 PID: 51 Comm: modprobe Not tainted 6.5.0-rc4-yocto-standard-dirty #15208
| Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
| pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : module_emit_plt_entry+0x184/0x1cc
| lr : module_emit_plt_entry+0x94/0x1cc
| sp : ffffffc0803bba60
[...]
| Call trace:
|  module_emit_plt_entry+0x184/0x1cc
|  apply_relocate_add+0x2bc/0x8e4
|  load_module+0xe34/0x1bd4
|  init_module_from_file+0x84/0xc0
|  __arm64_sys_finit_module+0x1b8/0x27c
|  invoke_syscall.constprop.0+0x5c/0x104
|  do_el0_svc+0x58/0x160
|  el0_svc+0x38/0x110
|  el0t_64_sync_handler+0xc0/0xc4
|  el0t_64_sync+0x190/0x194

Instead of duplicating module_init_layout_section()s logic, expose it.

Reported-by: Adam Johnston <adam.johnston@arm.com>
Fixes: 055f23b74b20 ("module: check for exit sections in layout_sections() instead of module_init_section()")
Cc: stable@vger.kernel.org
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 include/linux/moduleloader.h |    5 +++++
 kernel/module.c              |    2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

--- a/include/linux/moduleloader.h
+++ b/include/linux/moduleloader.h
@@ -39,6 +39,11 @@ bool module_init_section(const char *nam
  */
 bool module_exit_section(const char *name);
 
+/* Describes whether within_module_init() will consider this an init section
+ * or not. This behaviour changes with CONFIG_MODULE_UNLOAD.
+ */
+bool module_init_layout_section(const char *sname);
+
 /*
  * Apply the given relocation to the (simplified) ELF.  Return -error
  * or 0.
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2407,7 +2407,7 @@ static long get_offset(struct module *mo
 	return ret;
 }
 
-static bool module_init_layout_section(const char *sname)
+bool module_init_layout_section(const char *sname)
 {
 #ifndef CONFIG_MODULE_UNLOAD
 	if (module_exit_section(sname))



  parent reply	other threads:[~2023-08-31 11:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-31 11:10 [PATCH 5.15 0/9] 5.15.130-rc1 review Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 1/9] ACPI: thermal: Drop nocrt parameter Greg Kroah-Hartman
2023-08-31 11:10 ` Greg Kroah-Hartman [this message]
2023-08-31 11:10 ` [PATCH 5.15 3/9] arm64: module-plts: inline linux/moduleloader.h Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 4/9] arm64: module: Use module_init_layout_section() to spot init sections Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 5/9] ARM: " Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 6/9] rcu: Prevent expedited GP from enabling tick on offline CPU Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 7/9] rcu-tasks: Fix IPI failure handling in trc_wait_for_one_reader Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 8/9] rcu-tasks: Wait for trc_read_check_handler() IPIs Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 9/9] rcu-tasks: Add trc_inspect_reader() checks for exiting critical section Greg Kroah-Hartman
2023-08-31 20:43 ` [PATCH 5.15 0/9] 5.15.130-rc1 review Florian Fainelli
2023-09-01  1:01 ` SeongJae Park
2023-09-01  6:23 ` Ron Economos
2023-09-01  9:39 ` Sudip Mukherjee (Codethink)
2023-09-01 11:03 ` Naresh Kamboju
2023-09-01 15:35 ` Shuah Khan
2023-09-01 18:44 ` Jon Hunter
2023-09-02  4:20 ` Guenter Roeck

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=20230831110830.160595628@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=adam.johnston@arm.com \
    --cc=james.morse@arm.com \
    --cc=mcgrof@kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).