On Wed, 8 Jul 2020 at 13:03, 彭浩(Richard) <richard.p...@oppo.com> wrote: >> >> >> On Tue, Jul 07, 2020 at 07:46:08AM -0400, Peng Hao wrote: >> >> 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+ >> >> Signed-off-by: Peng Hao <richard.p...@oppo.com> >> >> --- >> >> 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.
>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. Thanks.
