Re: [PATCH] arm64/module-plts: Consider the special case where plt_max_entries is 0

On Thu, 9 Jul 2020 at 09:50, 彭浩(Richard) [off-list ref] wrote:

On Wed, 8 Jul 2020 at 13:03, 彭浩(Richard) [off-list ref] wrote:

quoted

quoted

On Tue, Jul 07, 2020 at 07:46:08AM -0400, Peng Hao wrote:

quoted

quoted

If plt_max_entries is 0, a warning is triggered.
WARNING: CPU: 200 PID: 3000 at arch/arm64/kernel/module-plts.c:97 module_emit_plt_entry+0xa4/0x150

Which kernel are you seeing this with? There is a PLT-related change in
for-next/core, and I'd like to rule if out if possible.

5.6.0-rc3+

quoted

quoted

Signed-off-by: Peng Hao <redacted>
---
 arch/arm64/kernel/module-plts.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
index 65b08a74aec6..1868c9ac13f2 100644
--- a/arch/arm64/kernel/module-plts.c
+++ b/arch/arm64/kernel/module-plts.c

@@ -79,7 +79,8 @@ u64 module_emit_plt_entry(struct module *mod, Elf64_Shdr *sechdrs,
     int i = pltsec->plt_num_entries;
     int j = i - 1;
     u64 val = sym->st_value + rela->r_addend;
-
+    if (pltsec->plt_max_entries == 0)
+            return 0;

Hmm, but if there aren't any PLTs then how do we end up here?

We also returned 0 when warning was triggered.

That doesn't really answer the question.

Apparently, you are hitting a R_AARCH64_JUMP26 or R_AARCH64_CALL26
relocation that operates on a b or bl instruction that is more than
128 megabytes away from its target.

My understanding is that a module that calls functions that are not part of the module will use PLT.
Plt_max_entries =0 May occur if a module does not depend on other module functions.

A PLT slot is allocated for each b or bl instruction that refers to a
symbol that lives in a different section, either of the same module
(e.g., bl in .init calling into .text), of another module, or of the
core kernel.

I don't see how you end up with plt_max_entries in this case, though.
Are you sure you have CONFIG_RANDOMIZE_BASE enabled?

quoted

In module_frob_arch_sections(), we count all such relocations that
point to other sections, and allocate a PLT slot for each (and update
plt_max_entries) accordingly. So this means that the relocation in
question was disregarded, and this could happen for only two reasons:
- the branch instruction and its target are both in the same section,
in which case this section is *really* large,
- CONFIG_RANDOMIZE_BASE is disabled, but you are still ending up in a
situation where the modules are really far away from the core kernel
or from other modules.

Do you have a lot of [large] modules loaded when this happens?

I don’t think I have [large] modules.  I'll trace which module caused this warning.

Yes please.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel