Messages in this thread |  | | From | 彭浩(Richard) <> | Subject | Re:[PATCH] arm64/module-plts: Consider the special case where plt_max_entries is 0 | Date | Thu, 9 Jul 2020 07:18:01 +0000 |
| |
On Thu, 9 Jul 2020 at 09:50, 彭浩(Richard) <richard.peng@oppo.com> wrote: >> >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. if a module does not depend on other module functions, PLT entries in the module is equal to 0. If this is the case I don't think I need to do anything, just return 0.What do you think should be done about this situation? Any Suggestions? Thanks. >Are you sure you have CONFIG_RANDOMIZE_BASE enabled? > CONFIG_RANDOMIZE_BASE = y or n has this warning (two servers, kernel version is different).
>> >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. I can't print debug until someone else is not using the server.
|  |