Messages in this thread | | | From | 彭浩(Richard) <> | Subject | Re: [PATCH] arm64/module-plts: Consider the special case where plt_max_entries is 0 | Date | Fri, 10 Jul 2020 10:17:03 +0000 |
| |
On Thu, Jul 09, 2020 at 07:18:01AM +0000, Peng Hao(Richard) wrote: >> On Thu, 9 Jul 2020 at 09:50, Peng Hao (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. > >This brings me back to my earlier question: if there are no PLT entries in >the module, then count_plts() will not find any R_AARCH64_JUMP26 or >R_AARCH64_CALL26 relocations that require PLTs and will therefore return 0. >The absence of these relocations means that module_emit_plt_entry() will not >be called by apply_relocate_add(), and so your patch should have no effect. > >You seem to be saying that module_emit_plt_entry() _is_ being called, >despite count_plts() returning 0. One way that can happen is if PLTs are >needed for branches within a single, very large text section, but you also >say that's not the case. > One of yesterday's reply was wrong. Warning appears on the two servers whose CONFIG_RANDOMIZE_BASE is n. there is a server is someone copied a new config, which can enable CONFIG_RANDOMIZE_BASE, compiled the kernel, but has not restarted the host. @Ard
>So I think we need more information from you so that we can either reproduce >this ourselves, or better understand where things are going wrong. > After I add the print information, the module that triggered the warning differs each time I restart the host. >Finally, you said that your kernel is "5.6.0-rc3+". Are you able to >reproduce with mainline (5.8-rc4)? > I will try it. >Will > >P.S. whenever you reply, the mail threading breaks :( Maybe the mailbox client automatically appends Chinese characters. I'll adjust it and see if I can fix it.
| |