From: Michael Ellerman <mpe@ellerman.id.au>
To: Alex Ghiti <alex@ghiti.fr>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Stephen Rothwell <sfr@canb.auug.org.au>,
Alexei Starovoitov <ast@kernel.org>,
linux-next@vger.kernel.org, Zong Li <zong.li@sifive.com>,
Palmer Dabbelt <palmerdabbelt@google.com>
Subject: Re: [PATCH v2] powerpc: Do not consider weak unresolved symbol relocations as bad
Date: Fri, 31 Jan 2020 20:18:25 +1100 [thread overview]
Message-ID: <87wo98f0gu.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <8a8d45c6-4ad2-c682-abfb-3d97188d0d45@ghiti.fr>
Alex Ghiti <alex@ghiti.fr> writes:
> On 1/18/20 12:03 PM, Alexandre Ghiti wrote:
>> Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak
>> symbols that may be unresolved at link time which result in an absolute
>> relocation to 0. relocs_check.sh emits the following warning:
>>
>> "WARNING: 2 bad relocations
>> c000000001a41478 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start
>> c000000001a41480 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end"
>>
>> whereas those relocations are legitimate even for a relocatable kernel
>> compiled with -pie option.
>>
>> relocs_check.sh already excluded some weak unresolved symbols explicitly:
>> remove those hardcoded symbols and add some logic that parses the symbols
>> using nm, retrieves all the weak unresolved symbols and excludes those from
>> the list of the potential bad relocations.
>>
>> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
>> ---
>>
>> Changes in v2:
>> - Follow Stephen advice of using grep -F instead of looping over weak symbols
>> using read, patch is way smaller and cleaner.
>> - Add missing nm in comment
>>
>> arch/powerpc/Makefile.postlink | 4 ++--
>> arch/powerpc/tools/relocs_check.sh | 20 ++++++++++++--------
>> 2 files changed, 14 insertions(+), 10 deletions(-)
>>
...
>
> Hi guys,
>
>
> Any thought about that ?
>
> I do think this patch makes the whole check about absolute relocations
> clearer.
> And in the future, it will avoid anyone to spend some time on those
> "bad" relocations
> which actually aren't.
Sorry I missed the v2. Will pick it up.
cheers
next prev parent reply other threads:[~2020-01-31 9:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-18 17:03 [PATCH v2] powerpc: Do not consider weak unresolved symbol relocations as bad Alexandre Ghiti
2020-01-30 20:07 ` Alex Ghiti
2020-01-31 9:18 ` Michael Ellerman [this message]
2020-02-04 12:01 ` Michael Ellerman
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=87wo98f0gu.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=alex@ghiti.fr \
--cc=ast@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=palmerdabbelt@google.com \
--cc=paulus@samba.org \
--cc=sfr@canb.auug.org.au \
--cc=zong.li@sifive.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.