From: Will Deacon <will@kernel.org>
To: "彭浩(Richard)" <richard.peng@oppo.com>
Cc: "catalin.marinas@arm.com" <catalin.marinas@arm.com>,
Ard Biesheuvel <ardb@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64/module-plts: Consider the special case where plt_max_entries is 0
Date: Fri, 21 Aug 2020 12:17:01 +0100 [thread overview]
Message-ID: <20200821111700.GD20455@willie-the-truck> (raw)
In-Reply-To: <HKAPR02MB4291648701A6803290A17299E0610@HKAPR02MB4291.apcprd02.prod.outlook.com>
On Tue, Jul 14, 2020 at 08:48:11AM +0000, 彭浩(Richard) wrote:
> 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.
> 1.The module in question is the calling function from core kernel.( Ib_core.ko triggered the warning multiple times).
> 2. There are multiple threads loading IB_core.ko
> [ 73.388931] ###cpu=33, name=ib_core, core_plts=0, init_plts=0
> [ 73.402102] #### cpu=33,pid=2297,name=ib_core, module_emit_plt_entry:plt_num_entries=1, plt_max_entries=0 (warning)
> [ 73.439391] ###cpu=24, name=ib_core, core_plts=0, init_plts=0
> [ 73.448617] ###cpu=4, name=ib_core, core_plts=0, init_plts=0
> [ 73.547535] ###cpu=221, name=ib_core, core_plts=0, init_plts=0
> [ 75.198075] #### cpu=24,pid=2336,name=ib_core, module_emit_plt_entry:plt_num_entries=1, plt_max_entries=0 (warning)
> [ 75.489496] #### cpu=4,pid=2344,name=ib_core, module_emit_plt_entry:plt_num_entries=1, plt_max_entries=0(warning)
>
> I don't understand why count_plts returns 0 when CONFIG_RANDOMIZE_BASE=n for R_AARCH64_JUMP26 and R_AARCH64_CALL26.
>
> 3. Set CONFIG_ARM64_MODULE_PLTS=y and restart the server several times without triggering this warning.
Can you provide a means for us to reproduce this failure with an upstream
kernel, please? I really can't tell what's going on from the report. If I
can reproduce the problem locally, then I'm happy to take a look.
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next parent reply other threads:[~2020-08-21 11:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <HKAPR02MB4291648701A6803290A17299E0610@HKAPR02MB4291.apcprd02.prod.outlook.com>
2020-08-21 11:17 ` Will Deacon [this message]
[not found] <HKAPR02MB429186AF5DC0A187A345F3BCE0640@HKAPR02MB4291.apcprd02.prod.outlook.com>
2020-07-09 7:31 ` [PATCH] arm64/module-plts: Consider the special case where plt_max_entries is 0 Will Deacon
[not found] <HKAPR02MB42915BECBD71F5ABA0890533E0640@HKAPR02MB4291.apcprd02.prod.outlook.com>
2020-07-09 6:55 ` Ard Biesheuvel
[not found] <HKAPR02MB4291B970192A023778445B1BE0670@HKAPR02MB4291.apcprd02.prod.outlook.com>
2020-07-08 12:19 ` Ard Biesheuvel
2020-07-07 11:46 Peng Hao
2020-07-08 8:25 ` Will Deacon
2020-07-08 8:48 ` Ard Biesheuvel
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=20200821111700.GD20455@willie-the-truck \
--to=will@kernel.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.peng@oppo.com \
/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