All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Ghiti <alexandre@ghiti.fr>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-arm-kernel@lists.infradead.org, zong.li@sifive.com,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>
Subject: Re: linux-next: build warning after merge of the bpf-next tree
Date: Sat, 11 Jan 2020 09:06:00 -0500	[thread overview]
Message-ID: <3e6f298c-e428-fdee-47a8-14addc581501@ghiti.fr> (raw)
In-Reply-To: <CAADnVQLo5HEjTpTTRm=BtExuKifPtCJm+Hu_WP6yeyV-Er55Qg@mail.gmail.com>


On 1/10/20 6:18 PM, Alexei Starovoitov wrote:
> On Fri, Jan 10, 2020 at 2:28 PM Alexandre Ghiti <alexandre@ghiti.fr> wrote:
>> Hi guys,
>>
>> On 10/27/19 8:02 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>> Hi all,
>>>>
>>>> After merging the bpf-next tree, today's linux-next build (powerpc
>>>> ppc64_defconfig) produced this warning:
>>>>
>>>> WARNING: 2 bad relocations
>>>> c000000001998a48 R_PPC64_ADDR64    _binary__btf_vmlinux_bin_start
>>>> c000000001998a50 R_PPC64_ADDR64    _binary__btf_vmlinux_bin_end
>>>>
>>>> Introduced by commit
>>>>
>>>>     8580ac9404f6 ("bpf: Process in-kernel BTF")
>>> This warning now appears in the net-next tree build.
>>>
>>>
>> I bump that thread up because Zong also noticed that 2 new relocations for
>> those symbols appeared in my riscv relocatable kernel branch following
>> that commit.
>>
>> I also noticed 2 new relocations R_AARCH64_ABS64 appearing in arm64 kernel.
>>
>> Those 2 weak undefined symbols have existed since commit
>> 341dfcf8d78e ("btf: expose BTF info through sysfs") but this is the fact
>> to declare those symbols into btf.c that produced those relocations.
>>
>> I'm not sure what this all means, but this is not something I expected
>> for riscv for
>> a kernel linked with -shared/-fpie. Maybe should we just leave them to
>> zero ?
>>
>> I think that deserves a deeper look if someone understands all this
>> better than I do.
> Are you saying there is a warning for arm64 as well?


Nop.


> Can ppc folks explain the above warning?
> What does it mean "2 bad relocations"?


This is what I'd like to understand too, it is not clear in
the ppc tool that outputs this message why it is considered 'bad'.


> The code is doing:
> extern char __weak _binary__btf_vmlinux_bin_start[];
> extern char __weak _binary__btf_vmlinux_bin_end[];
> Since they are weak they should be zero when not defined.
> What's the issue?


There likely is no issue, I just want to make sure those relocations
are legitimate and I want to understand what we should do with those.

At the moment arm64 does not relocate those at runtime and purely
ignore them: is this the right thing to do ?



WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Ghiti <alexandre@ghiti.fr>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Networking <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	zong.li@sifive.com, Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: linux-next: build warning after merge of the bpf-next tree
Date: Sat, 11 Jan 2020 09:06:00 -0500	[thread overview]
Message-ID: <3e6f298c-e428-fdee-47a8-14addc581501@ghiti.fr> (raw)
In-Reply-To: <CAADnVQLo5HEjTpTTRm=BtExuKifPtCJm+Hu_WP6yeyV-Er55Qg@mail.gmail.com>


On 1/10/20 6:18 PM, Alexei Starovoitov wrote:
> On Fri, Jan 10, 2020 at 2:28 PM Alexandre Ghiti <alexandre@ghiti.fr> wrote:
>> Hi guys,
>>
>> On 10/27/19 8:02 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>> Hi all,
>>>>
>>>> After merging the bpf-next tree, today's linux-next build (powerpc
>>>> ppc64_defconfig) produced this warning:
>>>>
>>>> WARNING: 2 bad relocations
>>>> c000000001998a48 R_PPC64_ADDR64    _binary__btf_vmlinux_bin_start
>>>> c000000001998a50 R_PPC64_ADDR64    _binary__btf_vmlinux_bin_end
>>>>
>>>> Introduced by commit
>>>>
>>>>     8580ac9404f6 ("bpf: Process in-kernel BTF")
>>> This warning now appears in the net-next tree build.
>>>
>>>
>> I bump that thread up because Zong also noticed that 2 new relocations for
>> those symbols appeared in my riscv relocatable kernel branch following
>> that commit.
>>
>> I also noticed 2 new relocations R_AARCH64_ABS64 appearing in arm64 kernel.
>>
>> Those 2 weak undefined symbols have existed since commit
>> 341dfcf8d78e ("btf: expose BTF info through sysfs") but this is the fact
>> to declare those symbols into btf.c that produced those relocations.
>>
>> I'm not sure what this all means, but this is not something I expected
>> for riscv for
>> a kernel linked with -shared/-fpie. Maybe should we just leave them to
>> zero ?
>>
>> I think that deserves a deeper look if someone understands all this
>> better than I do.
> Are you saying there is a warning for arm64 as well?


Nop.


> Can ppc folks explain the above warning?
> What does it mean "2 bad relocations"?


This is what I'd like to understand too, it is not clear in
the ppc tool that outputs this message why it is considered 'bad'.


> The code is doing:
> extern char __weak _binary__btf_vmlinux_bin_start[];
> extern char __weak _binary__btf_vmlinux_bin_end[];
> Since they are weak they should be zero when not defined.
> What's the issue?


There likely is no issue, I just want to make sure those relocations
are legitimate and I want to understand what we should do with those.

At the moment arm64 does not relocate those at runtime and purely
ignore them: is this the right thing to do ?



WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Ghiti <alexandre@ghiti.fr>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Networking <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	zong.li@sifive.com, Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: linux-next: build warning after merge of the bpf-next tree
Date: Sat, 11 Jan 2020 09:06:00 -0500	[thread overview]
Message-ID: <3e6f298c-e428-fdee-47a8-14addc581501@ghiti.fr> (raw)
In-Reply-To: <CAADnVQLo5HEjTpTTRm=BtExuKifPtCJm+Hu_WP6yeyV-Er55Qg@mail.gmail.com>


On 1/10/20 6:18 PM, Alexei Starovoitov wrote:
> On Fri, Jan 10, 2020 at 2:28 PM Alexandre Ghiti <alexandre@ghiti.fr> wrote:
>> Hi guys,
>>
>> On 10/27/19 8:02 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>> Hi all,
>>>>
>>>> After merging the bpf-next tree, today's linux-next build (powerpc
>>>> ppc64_defconfig) produced this warning:
>>>>
>>>> WARNING: 2 bad relocations
>>>> c000000001998a48 R_PPC64_ADDR64    _binary__btf_vmlinux_bin_start
>>>> c000000001998a50 R_PPC64_ADDR64    _binary__btf_vmlinux_bin_end
>>>>
>>>> Introduced by commit
>>>>
>>>>     8580ac9404f6 ("bpf: Process in-kernel BTF")
>>> This warning now appears in the net-next tree build.
>>>
>>>
>> I bump that thread up because Zong also noticed that 2 new relocations for
>> those symbols appeared in my riscv relocatable kernel branch following
>> that commit.
>>
>> I also noticed 2 new relocations R_AARCH64_ABS64 appearing in arm64 kernel.
>>
>> Those 2 weak undefined symbols have existed since commit
>> 341dfcf8d78e ("btf: expose BTF info through sysfs") but this is the fact
>> to declare those symbols into btf.c that produced those relocations.
>>
>> I'm not sure what this all means, but this is not something I expected
>> for riscv for
>> a kernel linked with -shared/-fpie. Maybe should we just leave them to
>> zero ?
>>
>> I think that deserves a deeper look if someone understands all this
>> better than I do.
> Are you saying there is a warning for arm64 as well?


Nop.


> Can ppc folks explain the above warning?
> What does it mean "2 bad relocations"?


This is what I'd like to understand too, it is not clear in
the ppc tool that outputs this message why it is considered 'bad'.


> The code is doing:
> extern char __weak _binary__btf_vmlinux_bin_start[];
> extern char __weak _binary__btf_vmlinux_bin_end[];
> Since they are weak they should be zero when not defined.
> What's the issue?


There likely is no issue, I just want to make sure those relocations
are legitimate and I want to understand what we should do with those.

At the moment arm64 does not relocate those at runtime and purely
ignore them: is this the right thing to do ?



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-01-11 14:06 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17 23:56 linux-next: build warning after merge of the bpf-next tree Stephen Rothwell
2019-10-17 23:56 ` Stephen Rothwell
2019-10-18  5:01 ` Alexei Starovoitov
2019-10-18  5:01   ` Alexei Starovoitov
2019-10-28  0:02 ` Stephen Rothwell
2019-10-28  0:02   ` Stephen Rothwell
2020-01-10 22:28   ` Alexandre Ghiti
2020-01-10 22:28     ` Alexandre Ghiti
2020-01-10 22:28     ` Alexandre Ghiti
2020-01-10 23:18     ` Alexei Starovoitov
2020-01-10 23:18       ` Alexei Starovoitov
2020-01-10 23:18       ` Alexei Starovoitov
2020-01-11 14:06       ` Alexandre Ghiti [this message]
2020-01-11 14:06         ` Alexandre Ghiti
2020-01-11 14:06         ` Alexandre Ghiti
2020-01-11  0:20   ` Palmer Dabbelt
2020-01-11  0:20     ` Palmer Dabbelt
2020-01-11  0:20     ` Palmer Dabbelt
2020-01-11 14:31     ` Alexandre Ghiti
2020-01-11 14:31       ` Alexandre Ghiti
2020-01-11 14:31       ` Alexandre Ghiti
2020-01-13  4:33       ` Zong Li
2020-01-13  4:33         ` Zong Li
2020-01-13  4:33         ` Zong Li
2020-01-14  5:23         ` Alexei Starovoitov
2020-01-14  5:23           ` Alexei Starovoitov
2020-01-14  5:23           ` Alexei Starovoitov
2020-01-15 20:48           ` Alexandre Ghiti
2020-01-15 20:48             ` Alexandre Ghiti
2020-01-15 20:48             ` Alexandre Ghiti
  -- strict thread matches above, loose matches on Subject: below --
2024-02-06  4:33 Stephen Rothwell
2023-10-13  0:40 Stephen Rothwell
2023-10-13  5:30 ` Stephen Rothwell
2023-10-13 16:54   ` Martin KaFai Lau
2023-02-15  3:45 Stephen Rothwell
2023-02-06  3:54 Stephen Rothwell
2023-02-06  3:59 ` Alexei Starovoitov
2021-12-05 23:55 Stephen Rothwell
2021-12-06  0:43 ` Stephen Rothwell
2021-12-07  3:22   ` Andrii Nakryiko
2020-11-11  1:01 Stephen Rothwell
2020-11-11 14:03 ` Qian Cai
2020-11-11 18:15   ` Andrii Nakryiko
2020-07-14  2:16 Stephen Rothwell
2020-07-14  9:00 ` Jiri Olsa
2020-07-14  9:27   ` Geert Uytterhoeven
2020-07-14 10:33   ` Stephen Rothwell
2020-07-14 10:47     ` Jiri Olsa
2020-07-14 11:15       ` Jiri Olsa
2020-07-14 14:54         ` Alexei Starovoitov
2019-03-24 22:28 Stephen Rothwell
2019-03-24 22:39 ` Willem de Bruijn
2018-05-09  4:49 Stephen Rothwell

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=3e6f298c-e428-fdee-47a8-14addc581501@ghiti.fr \
    --to=alexandre@ghiti.fr \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.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.