All of lore.kernel.org
 help / color / mirror / Atom feed
* linux-next: build warning after merge of the bpf-next tree
@ 2019-10-17 23:56 ` Stephen Rothwell
  0 siblings, 0 replies; 46+ messages in thread
From: Stephen Rothwell @ 2019-10-17 23:56 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, ppc-dev

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

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")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* linux-next: build warning after merge of the bpf-next tree
@ 2019-10-17 23:56 ` Stephen Rothwell
  0 siblings, 0 replies; 46+ messages in thread
From: Stephen Rothwell @ 2019-10-17 23:56 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, ppc-dev, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

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")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2019-10-17 23:56 ` Stephen Rothwell
@ 2019-10-18  5:01   ` Alexei Starovoitov
  -1 siblings, 0 replies; 46+ messages in thread
From: Alexei Starovoitov @ 2019-10-18  5:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List, ppc-dev

On Fri, Oct 18, 2019 at 10:56:57AM +1100, Stephen Rothwell 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

Can ppc folks help me figure out what this warning means?


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2019-10-18  5:01   ` Alexei Starovoitov
  0 siblings, 0 replies; 46+ messages in thread
From: Alexei Starovoitov @ 2019-10-18  5:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Borkmann, Networking, Alexei Starovoitov,
	Linux Kernel Mailing List, Linux Next Mailing List, ppc-dev

On Fri, Oct 18, 2019 at 10:56:57AM +1100, Stephen Rothwell 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

Can ppc folks help me figure out what this warning means?


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2019-10-17 23:56 ` Stephen Rothwell
@ 2019-10-28  0:02   ` Stephen Rothwell
  -1 siblings, 0 replies; 46+ messages in thread
From: Stephen Rothwell @ 2019-10-28  0:02 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, ppc-dev

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2019-10-28  0:02   ` Stephen Rothwell
  0 siblings, 0 replies; 46+ messages in thread
From: Stephen Rothwell @ 2019-10-28  0:02 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, ppc-dev, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: Re: linux-next: build warning after merge of the bpf-next tree
  2019-10-28  0:02   ` Stephen Rothwell
  (?)
@ 2020-01-10 22:28     ` Alexandre Ghiti
  -1 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-10 22:28 UTC (permalink / raw)
  To: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, ppc-dev,
	linux-arm-kernel, zong.li

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.

Alex


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-10 22:28     ` Alexandre Ghiti
  0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-10 22:28 UTC (permalink / raw)
  To: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: zong.li, Linux Next Mailing List, ppc-dev,
	Linux Kernel Mailing List, linux-arm-kernel

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.

Alex


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-10 22:28     ` Alexandre Ghiti
  0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-10 22:28 UTC (permalink / raw)
  To: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: zong.li, Linux Next Mailing List, ppc-dev,
	Linux Kernel Mailing List, linux-arm-kernel

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.

Alex


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

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: Re: linux-next: build warning after merge of the bpf-next tree
  2020-01-10 22:28     ` Alexandre Ghiti
  (?)
@ 2020-01-10 23:18       ` Alexei Starovoitov
  -1 siblings, 0 replies; 46+ messages in thread
From: Alexei Starovoitov @ 2020-01-10 23:18 UTC (permalink / raw)
  To: Alexandre Ghiti
  Cc: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov,
	Networking, Linux Next Mailing List, Linux Kernel Mailing List,
	ppc-dev, linux-arm-kernel, zong.li, Andrii Nakryiko

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?
Can ppc folks explain the above warning?
What does it mean "2 bad relocations"?
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?

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-10 23:18       ` Alexei Starovoitov
  0 siblings, 0 replies; 46+ messages in thread
From: Alexei Starovoitov @ 2020-01-10 23:18 UTC (permalink / raw)
  To: Alexandre Ghiti
  Cc: Stephen Rothwell, Daniel Borkmann, Networking,
	Linux Kernel Mailing List, Alexei Starovoitov,
	Linux Next Mailing List, zong.li, Andrii Nakryiko, ppc-dev,
	linux-arm-kernel

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?
Can ppc folks explain the above warning?
What does it mean "2 bad relocations"?
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?

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-10 23:18       ` Alexei Starovoitov
  0 siblings, 0 replies; 46+ messages in thread
From: Alexei Starovoitov @ 2020-01-10 23:18 UTC (permalink / raw)
  To: Alexandre Ghiti
  Cc: Stephen Rothwell, Daniel Borkmann, Networking,
	Linux Kernel Mailing List, Alexei Starovoitov,
	Linux Next Mailing List, zong.li, Andrii Nakryiko, ppc-dev,
	linux-arm-kernel

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?
Can ppc folks explain the above warning?
What does it mean "2 bad relocations"?
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?

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

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: Re: linux-next: build warning after merge of the bpf-next tree
  2019-10-28  0:02   ` Stephen Rothwell
  (?)
@ 2020-01-11  0:20     ` Palmer Dabbelt
  -1 siblings, 0 replies; 46+ messages in thread
From: Palmer Dabbelt @ 2020-01-11  0:20 UTC (permalink / raw)
  To: alexandre
  Cc: Stephen Rothwell, daniel, ast, netdev, linux-next, linux-kernel,
	linuxppc-dev, linux-arm-kernel, zong.li

On Fri, 10 Jan 2020 14:28:17 PST (-0800), 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.

Can you give me a pointer to your tree and how to build a relocatable kernel?
Weak undefined symbols have the absolute value 0, but the kernel is linked at
an address such that 0 can't be reached by normal means.  When I added support
to binutils for this I did it in a way that required almost no code --
essetially I just stopped dissallowing x0 as a possible base register for PCREL
relocations, which results in 0 always being accessible.  I just wanted to get
the kernel to build again, so I didn't worry about chasing around all the
addressing modes.  The PIC/PIE support generates different relocations and I
wouldn't be surprised if I just missed one (or more likely all) of them.

It's probably a simple fix, though I feel like every time I say that about the
linker I end up spending a month in there...

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-11  0:20     ` Palmer Dabbelt
  0 siblings, 0 replies; 46+ messages in thread
From: Palmer Dabbelt @ 2020-01-11  0:20 UTC (permalink / raw)
  To: alexandre
  Cc: Stephen Rothwell, daniel, netdev, linux-kernel, ast, linux-next,
	zong.li, linuxppc-dev, linux-arm-kernel

On Fri, 10 Jan 2020 14:28:17 PST (-0800), 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.

Can you give me a pointer to your tree and how to build a relocatable kernel?
Weak undefined symbols have the absolute value 0, but the kernel is linked at
an address such that 0 can't be reached by normal means.  When I added support
to binutils for this I did it in a way that required almost no code --
essetially I just stopped dissallowing x0 as a possible base register for PCREL
relocations, which results in 0 always being accessible.  I just wanted to get
the kernel to build again, so I didn't worry about chasing around all the
addressing modes.  The PIC/PIE support generates different relocations and I
wouldn't be surprised if I just missed one (or more likely all) of them.

It's probably a simple fix, though I feel like every time I say that about the
linker I end up spending a month in there...

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-11  0:20     ` Palmer Dabbelt
  0 siblings, 0 replies; 46+ messages in thread
From: Palmer Dabbelt @ 2020-01-11  0:20 UTC (permalink / raw)
  To: alexandre
  Cc: Stephen Rothwell, daniel, netdev, linux-kernel, ast, linux-next,
	zong.li, linuxppc-dev, linux-arm-kernel

On Fri, 10 Jan 2020 14:28:17 PST (-0800), 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.

Can you give me a pointer to your tree and how to build a relocatable kernel?
Weak undefined symbols have the absolute value 0, but the kernel is linked at
an address such that 0 can't be reached by normal means.  When I added support
to binutils for this I did it in a way that required almost no code --
essetially I just stopped dissallowing x0 as a possible base register for PCREL
relocations, which results in 0 always being accessible.  I just wanted to get
the kernel to build again, so I didn't worry about chasing around all the
addressing modes.  The PIC/PIE support generates different relocations and I
wouldn't be surprised if I just missed one (or more likely all) of them.

It's probably a simple fix, though I feel like every time I say that about the
linker I end up spending a month in there...

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

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-01-10 23:18       ` Alexei Starovoitov
  (?)
@ 2020-01-11 14:06         ` Alexandre Ghiti
  -1 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-11 14:06 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov,
	Networking, Linux Next Mailing List, Linux Kernel Mailing List,
	ppc-dev, linux-arm-kernel, zong.li, Andrii Nakryiko


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 ?



^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-11 14:06         ` Alexandre Ghiti
  0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-11 14:06 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Stephen Rothwell, Daniel Borkmann, Networking,
	Linux Kernel Mailing List, Alexei Starovoitov,
	Linux Next Mailing List, zong.li, Andrii Nakryiko, ppc-dev,
	linux-arm-kernel


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 ?



^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-11 14:06         ` Alexandre Ghiti
  0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-11 14:06 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Stephen Rothwell, Daniel Borkmann, Networking,
	Linux Kernel Mailing List, Alexei Starovoitov,
	Linux Next Mailing List, zong.li, Andrii Nakryiko, ppc-dev,
	linux-arm-kernel


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

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-01-11  0:20     ` Palmer Dabbelt
  (?)
@ 2020-01-11 14:31       ` Alexandre Ghiti
  -1 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-11 14:31 UTC (permalink / raw)
  To: Palmer Dabbelt
  Cc: Stephen Rothwell, daniel, ast, netdev, linux-next, linux-kernel,
	linuxppc-dev, linux-arm-kernel, zong.li


On 1/10/20 7:20 PM, Palmer Dabbelt wrote:
> On Fri, 10 Jan 2020 14:28:17 PST (-0800), 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.
>
> Can you give me a pointer to your tree and how to build a relocatable 
> kernel?
> Weak undefined symbols have the absolute value 0,


So according to you the 2 new relocations R_RISCV_64 are normal and 
should not
be modified at runtime right ?


> but the kernel is linked at
> an address such that 0 can't be reached by normal means.  When I added 
> support
> to binutils for this I did it in a way that required almost no code --
> essetially I just stopped dissallowing x0 as a possible base register 
> for PCREL
> relocations, which results in 0 always being accessible.  I just 
> wanted to get
> the kernel to build again, so I didn't worry about chasing around all the
> addressing modes.  The PIC/PIE support generates different relocations 
> and I
> wouldn't be surprised if I just missed one (or more likely all) of them.
>
> It's probably a simple fix, though I feel like every time I say that 
> about the
> linker I end up spending a month in there...

You can find it here:

https://github.com/AlexGhiti/riscv-linux/tree/int/alex/riscv_relocatable_v1

Zong fixed the bug introduced by those 2 new relocations and everything 
works
like a charm, so I'm not sure you have to dig in the linker :)

Alex


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-11 14:31       ` Alexandre Ghiti
  0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-11 14:31 UTC (permalink / raw)
  To: Palmer Dabbelt
  Cc: Stephen Rothwell, daniel, netdev, linux-kernel, ast, linux-next,
	zong.li, linuxppc-dev, linux-arm-kernel


On 1/10/20 7:20 PM, Palmer Dabbelt wrote:
> On Fri, 10 Jan 2020 14:28:17 PST (-0800), 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.
>
> Can you give me a pointer to your tree and how to build a relocatable 
> kernel?
> Weak undefined symbols have the absolute value 0,


So according to you the 2 new relocations R_RISCV_64 are normal and 
should not
be modified at runtime right ?


> but the kernel is linked at
> an address such that 0 can't be reached by normal means.  When I added 
> support
> to binutils for this I did it in a way that required almost no code --
> essetially I just stopped dissallowing x0 as a possible base register 
> for PCREL
> relocations, which results in 0 always being accessible.  I just 
> wanted to get
> the kernel to build again, so I didn't worry about chasing around all the
> addressing modes.  The PIC/PIE support generates different relocations 
> and I
> wouldn't be surprised if I just missed one (or more likely all) of them.
>
> It's probably a simple fix, though I feel like every time I say that 
> about the
> linker I end up spending a month in there...

You can find it here:

https://github.com/AlexGhiti/riscv-linux/tree/int/alex/riscv_relocatable_v1

Zong fixed the bug introduced by those 2 new relocations and everything 
works
like a charm, so I'm not sure you have to dig in the linker :)

Alex


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-11 14:31       ` Alexandre Ghiti
  0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-11 14:31 UTC (permalink / raw)
  To: Palmer Dabbelt
  Cc: Stephen Rothwell, daniel, netdev, linux-kernel, ast, linux-next,
	zong.li, linuxppc-dev, linux-arm-kernel


On 1/10/20 7:20 PM, Palmer Dabbelt wrote:
> On Fri, 10 Jan 2020 14:28:17 PST (-0800), 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.
>
> Can you give me a pointer to your tree and how to build a relocatable 
> kernel?
> Weak undefined symbols have the absolute value 0,


So according to you the 2 new relocations R_RISCV_64 are normal and 
should not
be modified at runtime right ?


> but the kernel is linked at
> an address such that 0 can't be reached by normal means.  When I added 
> support
> to binutils for this I did it in a way that required almost no code --
> essetially I just stopped dissallowing x0 as a possible base register 
> for PCREL
> relocations, which results in 0 always being accessible.  I just 
> wanted to get
> the kernel to build again, so I didn't worry about chasing around all the
> addressing modes.  The PIC/PIE support generates different relocations 
> and I
> wouldn't be surprised if I just missed one (or more likely all) of them.
>
> It's probably a simple fix, though I feel like every time I say that 
> about the
> linker I end up spending a month in there...

You can find it here:

https://github.com/AlexGhiti/riscv-linux/tree/int/alex/riscv_relocatable_v1

Zong fixed the bug introduced by those 2 new relocations and everything 
works
like a charm, so I'm not sure you have to dig in the linker :)

Alex


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

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-01-11 14:31       ` Alexandre Ghiti
  (?)
@ 2020-01-13  4:33         ` Zong Li
  -1 siblings, 0 replies; 46+ messages in thread
From: Zong Li @ 2020-01-13  4:33 UTC (permalink / raw)
  To: Alexandre Ghiti
  Cc: Palmer Dabbelt, Stephen Rothwell, daniel, ast, netdev,
	linux-next, linux-kernel@vger.kernel.org List, linuxppc-dev,
	linux-arm-kernel

On Sat, Jan 11, 2020 at 10:31 PM Alexandre Ghiti <alexandre@ghiti.fr> wrote:
>
>
> On 1/10/20 7:20 PM, Palmer Dabbelt wrote:
> > On Fri, 10 Jan 2020 14:28:17 PST (-0800), 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.
> >
> > Can you give me a pointer to your tree and how to build a relocatable
> > kernel?
> > Weak undefined symbols have the absolute value 0,
>
>
> So according to you the 2 new relocations R_RISCV_64 are normal and
> should not
> be modified at runtime right ?
>
>
> > but the kernel is linked at
> > an address such that 0 can't be reached by normal means.  When I added
> > support
> > to binutils for this I did it in a way that required almost no code --
> > essetially I just stopped dissallowing x0 as a possible base register
> > for PCREL
> > relocations, which results in 0 always being accessible.  I just
> > wanted to get
> > the kernel to build again, so I didn't worry about chasing around all the
> > addressing modes.  The PIC/PIE support generates different relocations
> > and I
> > wouldn't be surprised if I just missed one (or more likely all) of them.
> >
> > It's probably a simple fix, though I feel like every time I say that
> > about the
> > linker I end up spending a month in there...
>
> You can find it here:
>
> https://github.com/AlexGhiti/riscv-linux/tree/int/alex/riscv_relocatable_v1
>
> Zong fixed the bug introduced by those 2 new relocations and everything
> works
> like a charm, so I'm not sure you have to dig in the linker :)
>

I'm not quite familiar with btf, so I have no idea why there are two
weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")
as well, According on relocation mechanism, maybe it is unnecessary to
handle weak undefined symbol at this time, because there is no
substantive help to relocate the absolute value 0. I just simply
ignore the non-relative relocation types to make processing can go
forward, and it works for me based on v5.5-rc5.

> Alex
>

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-13  4:33         ` Zong Li
  0 siblings, 0 replies; 46+ messages in thread
From: Zong Li @ 2020-01-13  4:33 UTC (permalink / raw)
  To: Alexandre Ghiti
  Cc: Stephen Rothwell, daniel, netdev, Palmer Dabbelt, ast,
	linux-kernel@vger.kernel.org List, linux-next, linuxppc-dev,
	linux-arm-kernel

On Sat, Jan 11, 2020 at 10:31 PM Alexandre Ghiti <alexandre@ghiti.fr> wrote:
>
>
> On 1/10/20 7:20 PM, Palmer Dabbelt wrote:
> > On Fri, 10 Jan 2020 14:28:17 PST (-0800), 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.
> >
> > Can you give me a pointer to your tree and how to build a relocatable
> > kernel?
> > Weak undefined symbols have the absolute value 0,
>
>
> So according to you the 2 new relocations R_RISCV_64 are normal and
> should not
> be modified at runtime right ?
>
>
> > but the kernel is linked at
> > an address such that 0 can't be reached by normal means.  When I added
> > support
> > to binutils for this I did it in a way that required almost no code --
> > essetially I just stopped dissallowing x0 as a possible base register
> > for PCREL
> > relocations, which results in 0 always being accessible.  I just
> > wanted to get
> > the kernel to build again, so I didn't worry about chasing around all the
> > addressing modes.  The PIC/PIE support generates different relocations
> > and I
> > wouldn't be surprised if I just missed one (or more likely all) of them.
> >
> > It's probably a simple fix, though I feel like every time I say that
> > about the
> > linker I end up spending a month in there...
>
> You can find it here:
>
> https://github.com/AlexGhiti/riscv-linux/tree/int/alex/riscv_relocatable_v1
>
> Zong fixed the bug introduced by those 2 new relocations and everything
> works
> like a charm, so I'm not sure you have to dig in the linker :)
>

I'm not quite familiar with btf, so I have no idea why there are two
weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")
as well, According on relocation mechanism, maybe it is unnecessary to
handle weak undefined symbol at this time, because there is no
substantive help to relocate the absolute value 0. I just simply
ignore the non-relative relocation types to make processing can go
forward, and it works for me based on v5.5-rc5.

> Alex
>

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-13  4:33         ` Zong Li
  0 siblings, 0 replies; 46+ messages in thread
From: Zong Li @ 2020-01-13  4:33 UTC (permalink / raw)
  To: Alexandre Ghiti
  Cc: Stephen Rothwell, daniel, netdev, Palmer Dabbelt, ast,
	linux-kernel@vger.kernel.org List, linux-next, linuxppc-dev,
	linux-arm-kernel

On Sat, Jan 11, 2020 at 10:31 PM Alexandre Ghiti <alexandre@ghiti.fr> wrote:
>
>
> On 1/10/20 7:20 PM, Palmer Dabbelt wrote:
> > On Fri, 10 Jan 2020 14:28:17 PST (-0800), 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.
> >
> > Can you give me a pointer to your tree and how to build a relocatable
> > kernel?
> > Weak undefined symbols have the absolute value 0,
>
>
> So according to you the 2 new relocations R_RISCV_64 are normal and
> should not
> be modified at runtime right ?
>
>
> > but the kernel is linked at
> > an address such that 0 can't be reached by normal means.  When I added
> > support
> > to binutils for this I did it in a way that required almost no code --
> > essetially I just stopped dissallowing x0 as a possible base register
> > for PCREL
> > relocations, which results in 0 always being accessible.  I just
> > wanted to get
> > the kernel to build again, so I didn't worry about chasing around all the
> > addressing modes.  The PIC/PIE support generates different relocations
> > and I
> > wouldn't be surprised if I just missed one (or more likely all) of them.
> >
> > It's probably a simple fix, though I feel like every time I say that
> > about the
> > linker I end up spending a month in there...
>
> You can find it here:
>
> https://github.com/AlexGhiti/riscv-linux/tree/int/alex/riscv_relocatable_v1
>
> Zong fixed the bug introduced by those 2 new relocations and everything
> works
> like a charm, so I'm not sure you have to dig in the linker :)
>

I'm not quite familiar with btf, so I have no idea why there are two
weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")
as well, According on relocation mechanism, maybe it is unnecessary to
handle weak undefined symbol at this time, because there is no
substantive help to relocate the absolute value 0. I just simply
ignore the non-relative relocation types to make processing can go
forward, and it works for me based on v5.5-rc5.

> Alex
>

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

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-01-13  4:33         ` Zong Li
  (?)
@ 2020-01-14  5:23           ` Alexei Starovoitov
  -1 siblings, 0 replies; 46+ messages in thread
From: Alexei Starovoitov @ 2020-01-14  5:23 UTC (permalink / raw)
  To: Zong Li
  Cc: Alexandre Ghiti, Palmer Dabbelt, Stephen Rothwell,
	Daniel Borkmann, Alexei Starovoitov, Network Development,
	Linux-Next Mailing List, linux-kernel@vger.kernel.org List,
	ppc-dev, linux-arm-kernel

On Sun, Jan 12, 2020 at 8:33 PM Zong Li <zong.li@sifive.com> wrote:
>
> I'm not quite familiar with btf, so I have no idea why there are two
> weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")

I can explain what these weak symbols are for, but that won't change
the fact that compiler or linker are buggy. The weak symbols should work
in all cases and compiler should pick correct relocation.
In this case it sounds that compiler picked relative relocation and failed
to reach zero from that address.

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-14  5:23           ` Alexei Starovoitov
  0 siblings, 0 replies; 46+ messages in thread
From: Alexei Starovoitov @ 2020-01-14  5:23 UTC (permalink / raw)
  To: Zong Li
  Cc: Stephen Rothwell, Alexandre Ghiti, Daniel Borkmann,
	Network Development, Palmer Dabbelt, Alexei Starovoitov,
	linux-kernel@vger.kernel.org List, Linux-Next Mailing List,
	ppc-dev, linux-arm-kernel

On Sun, Jan 12, 2020 at 8:33 PM Zong Li <zong.li@sifive.com> wrote:
>
> I'm not quite familiar with btf, so I have no idea why there are two
> weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")

I can explain what these weak symbols are for, but that won't change
the fact that compiler or linker are buggy. The weak symbols should work
in all cases and compiler should pick correct relocation.
In this case it sounds that compiler picked relative relocation and failed
to reach zero from that address.

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-14  5:23           ` Alexei Starovoitov
  0 siblings, 0 replies; 46+ messages in thread
From: Alexei Starovoitov @ 2020-01-14  5:23 UTC (permalink / raw)
  To: Zong Li
  Cc: Stephen Rothwell, Alexandre Ghiti, Daniel Borkmann,
	Network Development, Palmer Dabbelt, Alexei Starovoitov,
	linux-kernel@vger.kernel.org List, Linux-Next Mailing List,
	ppc-dev, linux-arm-kernel

On Sun, Jan 12, 2020 at 8:33 PM Zong Li <zong.li@sifive.com> wrote:
>
> I'm not quite familiar with btf, so I have no idea why there are two
> weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")

I can explain what these weak symbols are for, but that won't change
the fact that compiler or linker are buggy. The weak symbols should work
in all cases and compiler should pick correct relocation.
In this case it sounds that compiler picked relative relocation and failed
to reach zero from that address.

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

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-01-14  5:23           ` Alexei Starovoitov
  (?)
@ 2020-01-15 20:48             ` Alexandre Ghiti
  -1 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-15 20:48 UTC (permalink / raw)
  To: Alexei Starovoitov, Zong Li
  Cc: Palmer Dabbelt, Stephen Rothwell, Daniel Borkmann,
	Alexei Starovoitov, Network Development, Linux-Next Mailing List,
	linux-kernel@vger.kernel.org List, ppc-dev, linux-arm-kernel

On 1/14/20 6:23 AM, Alexei Starovoitov wrote:
> On Sun, Jan 12, 2020 at 8:33 PM Zong Li<zong.li@sifive.com>  wrote:
>> I'm not quite familiar with btf, so I have no idea why there are two
>> weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")
> I can explain what these weak symbols are for, but that won't change
> the fact that compiler or linker are buggy. The weak symbols should work
> in all cases and compiler should pick correct relocation.
> In this case it sounds that compiler picked relative relocation and failed
> to reach zero from that address.

Sorry for the response delay: I now agree that there is nothing weird 
about those
relocations. All compiler/linker I took a look at (arm64, ppc64 and 
riscv64) correctly
emit an absolute relocation to the address 0 in case of a weak 
unresolved symbol,
so there's no buggy compiler/linker.

And regarding ppc warning, the kernel being compiled as -pie, the 
scripts looks
for absolute relocations which it considers as "bad", except for one 
that is known
to be weak and that is ignored: I have just sent a patch to fix this 
script so that weak
undefined symbol relocations are not considered as bad.

Thanks,

Alex



^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-15 20:48             ` Alexandre Ghiti
  0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-15 20:48 UTC (permalink / raw)
  To: Alexei Starovoitov, Zong Li
  Cc: Stephen Rothwell, Daniel Borkmann, Network Development,
	Palmer Dabbelt, Alexei Starovoitov,
	linux-kernel@vger.kernel.org List, Linux-Next Mailing List,
	ppc-dev, linux-arm-kernel

On 1/14/20 6:23 AM, Alexei Starovoitov wrote:
> On Sun, Jan 12, 2020 at 8:33 PM Zong Li<zong.li@sifive.com>  wrote:
>> I'm not quite familiar with btf, so I have no idea why there are two
>> weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")
> I can explain what these weak symbols are for, but that won't change
> the fact that compiler or linker are buggy. The weak symbols should work
> in all cases and compiler should pick correct relocation.
> In this case it sounds that compiler picked relative relocation and failed
> to reach zero from that address.

Sorry for the response delay: I now agree that there is nothing weird 
about those
relocations. All compiler/linker I took a look at (arm64, ppc64 and 
riscv64) correctly
emit an absolute relocation to the address 0 in case of a weak 
unresolved symbol,
so there's no buggy compiler/linker.

And regarding ppc warning, the kernel being compiled as -pie, the 
scripts looks
for absolute relocations which it considers as "bad", except for one 
that is known
to be weak and that is ignored: I have just sent a patch to fix this 
script so that weak
undefined symbol relocations are not considered as bad.

Thanks,

Alex



^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
@ 2020-01-15 20:48             ` Alexandre Ghiti
  0 siblings, 0 replies; 46+ messages in thread
From: Alexandre Ghiti @ 2020-01-15 20:48 UTC (permalink / raw)
  To: Alexei Starovoitov, Zong Li
  Cc: Stephen Rothwell, Daniel Borkmann, Network Development,
	Palmer Dabbelt, Alexei Starovoitov,
	linux-kernel@vger.kernel.org List, Linux-Next Mailing List,
	ppc-dev, linux-arm-kernel

On 1/14/20 6:23 AM, Alexei Starovoitov wrote:
> On Sun, Jan 12, 2020 at 8:33 PM Zong Li<zong.li@sifive.com>  wrote:
>> I'm not quite familiar with btf, so I have no idea why there are two
>> weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")
> I can explain what these weak symbols are for, but that won't change
> the fact that compiler or linker are buggy. The weak symbols should work
> in all cases and compiler should pick correct relocation.
> In this case it sounds that compiler picked relative relocation and failed
> to reach zero from that address.

Sorry for the response delay: I now agree that there is nothing weird 
about those
relocations. All compiler/linker I took a look at (arm64, ppc64 and 
riscv64) correctly
emit an absolute relocation to the address 0 in case of a weak 
unresolved symbol,
so there's no buggy compiler/linker.

And regarding ppc warning, the kernel being compiled as -pie, the 
scripts looks
for absolute relocations which it considers as "bad", except for one 
that is known
to be weak and that is ignored: I have just sent a patch to fix this 
script so that weak
undefined symbol relocations are not considered as bad.

Thanks,

Alex



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

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2021-12-06  0:43 ` Stephen Rothwell
@ 2021-12-07  3:22   ` Andrii Nakryiko
  0 siblings, 0 replies; 46+ messages in thread
From: Andrii Nakryiko @ 2021-12-07  3:22 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
	Networking, Linux Kernel Mailing List, Linux Next Mailing List

On Sun, Dec 5, 2021 at 4:44 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 6 Dec 2021 10:55:30 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > kernel/bpf/btf.c:6588:13: warning: 'purge_cand_cache' defined but not used [-Wunused-function]
> >  6588 | static void purge_cand_cache(struct btf *btf)
> >       |             ^~~~~~~~~~~~~~~~
> >
> > Introduced by commit
> >
> >   1e89106da253 ("bpf: Add bpf_core_add_cands() and wire it into bpf_core_apply_relo_insn().")
>
> And this is a build failure for my x86_64 allmodconfig build.  So I
> have used the bpf-next tree from next-20211202 again.

This should be fixed by [0] which I just applied to bpf-next, thanks
for letting us know! The reason you noticed this and we didn't is
because your version of pahole is probably older than what we use
typically and doesn't yet support kernel module BTFs.

  [0] https://patchwork.kernel.org/project/netdevbpf/patch/20211207014839.6976-1-alexei.starovoitov@gmail.com/


>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2021-12-05 23:55 Stephen Rothwell
@ 2021-12-06  0:43 ` Stephen Rothwell
  2021-12-07  3:22   ` Andrii Nakryiko
  0 siblings, 1 reply; 46+ messages in thread
From: Stephen Rothwell @ 2021-12-06  0:43 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf, Networking
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

Hi all,

On Mon, 6 Dec 2021 10:55:30 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> kernel/bpf/btf.c:6588:13: warning: 'purge_cand_cache' defined but not used [-Wunused-function]
>  6588 | static void purge_cand_cache(struct btf *btf)
>       |             ^~~~~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   1e89106da253 ("bpf: Add bpf_core_add_cands() and wire it into bpf_core_apply_relo_insn().")

And this is a build failure for my x86_64 allmodconfig build.  So I
have used the bpf-next tree from next-20211202 again.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* linux-next: build warning after merge of the bpf-next tree
@ 2021-12-05 23:55 Stephen Rothwell
  2021-12-06  0:43 ` Stephen Rothwell
  0 siblings, 1 reply; 46+ messages in thread
From: Stephen Rothwell @ 2021-12-05 23:55 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf, Networking
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

kernel/bpf/btf.c:6588:13: warning: 'purge_cand_cache' defined but not used [-Wunused-function]
 6588 | static void purge_cand_cache(struct btf *btf)
      |             ^~~~~~~~~~~~~~~~

Introduced by commit

  1e89106da253 ("bpf: Add bpf_core_add_cands() and wire it into bpf_core_apply_relo_insn().")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-11-11 14:03 ` Qian Cai
@ 2020-11-11 18:15   ` Andrii Nakryiko
  0 siblings, 0 replies; 46+ messages in thread
From: Andrii Nakryiko @ 2020-11-11 18:15 UTC (permalink / raw)
  To: Qian Cai
  Cc: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov,
	Networking, Andrii Nakryiko, Linux Kernel Mailing List,
	Linux Next Mailing List

On Wed, Nov 11, 2020 at 6:03 AM Qian Cai <cai@redhat.com> wrote:
>
> On Wed, 2020-11-11 at 12:01 +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > kernel/bpf/btf.c:4481:20: warning: 'btf_parse_module' defined but not used [-
> > Wunused-function]
> >  4481 | static struct btf *btf_parse_module(const char *module_name, const
> > void *data, unsigned int data_size)
> >       |                    ^~~~~~~~~~~~~~~~
> >
> > Introduced by commit
> >
> >   36e68442d1af ("bpf: Load and verify kernel module BTFs")
> >
>
> It loos like btf_parse_module() is only used when
> CONFIG_DEBUG_INFO_BTF_MODULES=y, so this should fix it.

Fixed already in [0].

  [0] https://patchwork.kernel.org/project/netdevbpf/patch/20201111040645.903494-1-andrii@kernel.org/

>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 0f1fd2669d69..e877eeebc616 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -4478,6 +4478,7 @@ struct btf *btf_parse_vmlinux(void)
>         return ERR_PTR(err);
>  }
>
> +#ifdef CONFIG_DEBUG_INFO_BTF_MODULES
>  static struct btf *btf_parse_module(const char *module_name, const void *data, unsigned int data_size)
>  {
>         struct btf_verifier_env *env = NULL;
> @@ -4546,6 +4547,7 @@ static struct btf *btf_parse_module(const char *module_name, const void *data, u
>         }
>         return ERR_PTR(err);
>  }
> +#endif /* CONFIG_DEBUG_INFO_BTF_MODULES */
>
>  struct btf *bpf_prog_get_target_btf(const struct bpf_prog *prog)
>  {
>

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-11-11  1:01 Stephen Rothwell
@ 2020-11-11 14:03 ` Qian Cai
  2020-11-11 18:15   ` Andrii Nakryiko
  0 siblings, 1 reply; 46+ messages in thread
From: Qian Cai @ 2020-11-11 14:03 UTC (permalink / raw)
  To: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Andrii Nakryiko, Linux Kernel Mailing List, Linux Next Mailing List

On Wed, 2020-11-11 at 12:01 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> kernel/bpf/btf.c:4481:20: warning: 'btf_parse_module' defined but not used [-
> Wunused-function]
>  4481 | static struct btf *btf_parse_module(const char *module_name, const
> void *data, unsigned int data_size)
>       |                    ^~~~~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   36e68442d1af ("bpf: Load and verify kernel module BTFs")
> 

It loos like btf_parse_module() is only used when
CONFIG_DEBUG_INFO_BTF_MODULES=y, so this should fix it.

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 0f1fd2669d69..e877eeebc616 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -4478,6 +4478,7 @@ struct btf *btf_parse_vmlinux(void)
 	return ERR_PTR(err);
 }
 
+#ifdef CONFIG_DEBUG_INFO_BTF_MODULES
 static struct btf *btf_parse_module(const char *module_name, const void *data, unsigned int data_size)
 {
 	struct btf_verifier_env *env = NULL;
@@ -4546,6 +4547,7 @@ static struct btf *btf_parse_module(const char *module_name, const void *data, u
 	}
 	return ERR_PTR(err);
 }
+#endif /* CONFIG_DEBUG_INFO_BTF_MODULES */
 
 struct btf *bpf_prog_get_target_btf(const struct bpf_prog *prog)
 {


^ permalink raw reply	[flat|nested] 46+ messages in thread

* linux-next: build warning after merge of the bpf-next tree
@ 2020-11-11  1:01 Stephen Rothwell
  2020-11-11 14:03 ` Qian Cai
  0 siblings, 1 reply; 46+ messages in thread
From: Stephen Rothwell @ 2020-11-11  1:01 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Andrii Nakryiko, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

kernel/bpf/btf.c:4481:20: warning: 'btf_parse_module' defined but not used [-Wunused-function]
 4481 | static struct btf *btf_parse_module(const char *module_name, const void *data, unsigned int data_size)
      |                    ^~~~~~~~~~~~~~~~

Introduced by commit

  36e68442d1af ("bpf: Load and verify kernel module BTFs")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-07-14 11:15       ` Jiri Olsa
@ 2020-07-14 14:54         ` Alexei Starovoitov
  0 siblings, 0 replies; 46+ messages in thread
From: Alexei Starovoitov @ 2020-07-14 14:54 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Stephen Rothwell, David Miller, Daniel Borkmann,
	Alexei Starovoitov, Networking, Linux Next Mailing List,
	Linux Kernel Mailing List, Jiri Olsa

On Tue, Jul 14, 2020 at 4:15 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Tue, Jul 14, 2020 at 12:47:02PM +0200, Jiri Olsa wrote:
> > On Tue, Jul 14, 2020 at 08:33:41PM +1000, Stephen Rothwell wrote:
> >
> > SNIP
> >
> > > > diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
> > > > index 948378ca73d4..a88cd4426398 100644
> > > > --- a/tools/bpf/resolve_btfids/Makefile
> > > > +++ b/tools/bpf/resolve_btfids/Makefile
> > > > @@ -16,6 +16,20 @@ else
> > > >    MAKEFLAGS=--no-print-directory
> > > >  endif
> > > >
> > > > +# always use the host compiler
> > > > +ifneq ($(LLVM),)
> > > > +HOSTAR  ?= llvm-ar
> > > > +HOSTCC  ?= clang
> > > > +HOSTLD  ?= ld.lld
> > > > +else
> > > > +HOSTAR  ?= ar
> > > > +HOSTCC  ?= gcc
> > > > +HOSTLD  ?= ld
> > > > +endif
> > > > +AR       = $(HOSTAR)
> > > > +CC       = $(HOSTCC)
> > > > +LD       = $(HOSTLD)
> > > > +
> > > >  OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
> > > >
> > > >  LIBBPF_SRC := $(srctree)/tools/lib/bpf/
> > > >
> > >
> > > Thanks for the quick response.  However, in the mean time the bpf-next
> > > tree has been merged into the net-next tree, so these fixes will be
> > > needed there ASAP.
> >
> > I just posted it
>
> ugh, you said net-next..
>
> David, do you need me to repost with net-next tag?
>   https://lore.kernel.org/bpf/20200714102534.299280-1-jolsa@kernel.org/T/

NO. The fixes must go into bpf-next first.

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-07-14 10:47     ` Jiri Olsa
@ 2020-07-14 11:15       ` Jiri Olsa
  2020-07-14 14:54         ` Alexei Starovoitov
  0 siblings, 1 reply; 46+ messages in thread
From: Jiri Olsa @ 2020-07-14 11:15 UTC (permalink / raw)
  To: Stephen Rothwell, David Miller
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List, Jiri Olsa

On Tue, Jul 14, 2020 at 12:47:02PM +0200, Jiri Olsa wrote:
> On Tue, Jul 14, 2020 at 08:33:41PM +1000, Stephen Rothwell wrote:
> 
> SNIP
> 
> > > diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
> > > index 948378ca73d4..a88cd4426398 100644
> > > --- a/tools/bpf/resolve_btfids/Makefile
> > > +++ b/tools/bpf/resolve_btfids/Makefile
> > > @@ -16,6 +16,20 @@ else
> > >    MAKEFLAGS=--no-print-directory
> > >  endif
> > >  
> > > +# always use the host compiler
> > > +ifneq ($(LLVM),)
> > > +HOSTAR  ?= llvm-ar
> > > +HOSTCC  ?= clang
> > > +HOSTLD  ?= ld.lld
> > > +else
> > > +HOSTAR  ?= ar
> > > +HOSTCC  ?= gcc
> > > +HOSTLD  ?= ld
> > > +endif
> > > +AR       = $(HOSTAR)
> > > +CC       = $(HOSTCC)
> > > +LD       = $(HOSTLD)
> > > +
> > >  OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
> > >  
> > >  LIBBPF_SRC := $(srctree)/tools/lib/bpf/
> > > 
> > 
> > Thanks for the quick response.  However, in the mean time the bpf-next
> > tree has been merged into the net-next tree, so these fixes will be
> > needed there ASAP.
> 
> I just posted it

ugh, you said net-next..

David, do you need me to repost with net-next tag?
  https://lore.kernel.org/bpf/20200714102534.299280-1-jolsa@kernel.org/T/

jirka


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-07-14 10:33   ` Stephen Rothwell
@ 2020-07-14 10:47     ` Jiri Olsa
  2020-07-14 11:15       ` Jiri Olsa
  0 siblings, 1 reply; 46+ messages in thread
From: Jiri Olsa @ 2020-07-14 10:47 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List, Jiri Olsa,
	David Miller

On Tue, Jul 14, 2020 at 08:33:41PM +1000, Stephen Rothwell wrote:

SNIP

> > diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
> > index 948378ca73d4..a88cd4426398 100644
> > --- a/tools/bpf/resolve_btfids/Makefile
> > +++ b/tools/bpf/resolve_btfids/Makefile
> > @@ -16,6 +16,20 @@ else
> >    MAKEFLAGS=--no-print-directory
> >  endif
> >  
> > +# always use the host compiler
> > +ifneq ($(LLVM),)
> > +HOSTAR  ?= llvm-ar
> > +HOSTCC  ?= clang
> > +HOSTLD  ?= ld.lld
> > +else
> > +HOSTAR  ?= ar
> > +HOSTCC  ?= gcc
> > +HOSTLD  ?= ld
> > +endif
> > +AR       = $(HOSTAR)
> > +CC       = $(HOSTCC)
> > +LD       = $(HOSTLD)
> > +
> >  OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
> >  
> >  LIBBPF_SRC := $(srctree)/tools/lib/bpf/
> > 
> 
> Thanks for the quick response.  However, in the mean time the bpf-next
> tree has been merged into the net-next tree, so these fixes will be
> needed there ASAP.

I just posted it

jirka


^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  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
  1 sibling, 1 reply; 46+ messages in thread
From: Stephen Rothwell @ 2020-07-14 10:33 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List, Jiri Olsa,
	David Miller

[-- Attachment #1: Type: text/plain, Size: 3817 bytes --]

Hi Jiri,

On Tue, 14 Jul 2020 11:00:48 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Tue, Jul 14, 2020 at 12:16:08PM +1000, Stephen Rothwell wrote:
> > 
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> > 
> > ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
> > 
> > Presumably ntroduced by the merge of the resolve_btfids branch.  
> 
> missing one more #ifdef.. chage below fixes it for me,
> it's squashed with the fix for the arm build, I'll post 
> both fixes today
> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> index fe019774f8a7..2f9754a4ab2b 100644
> --- a/include/linux/btf_ids.h
> +++ b/include/linux/btf_ids.h
> @@ -3,6 +3,8 @@
>  #ifndef _LINUX_BTF_IDS_H
>  #define _LINUX_BTF_IDS_H
>  
> +#ifdef CONFIG_DEBUG_INFO_BTF
> +
>  #include <linux/compiler.h> /* for __PASTE */
>  
>  /*
> @@ -21,7 +23,7 @@
>  asm(							\
>  ".pushsection " BTF_IDS_SECTION ",\"a\";       \n"	\
>  ".local " #symbol " ;                          \n"	\
> -".type  " #symbol ", @object;                  \n"	\
> +".type  " #symbol ", STT_OBJECT;               \n"	\
>  ".size  " #symbol ", 4;                        \n"	\
>  #symbol ":                                     \n"	\
>  ".zero 4                                       \n"	\
> @@ -83,5 +85,12 @@ asm(							\
>  ".zero 4                                       \n"	\
>  ".popsection;                                  \n");
>  
> +#else
> +
> +#define BTF_ID_LIST(name) u32 name[5];
> +#define BTF_ID(prefix, name)
> +#define BTF_ID_UNUSED
> +
> +#endif /* CONFIG_DEBUG_INFO_BTF */
>  
>  #endif
> diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
> index 948378ca73d4..a88cd4426398 100644
> --- a/tools/bpf/resolve_btfids/Makefile
> +++ b/tools/bpf/resolve_btfids/Makefile
> @@ -16,6 +16,20 @@ else
>    MAKEFLAGS=--no-print-directory
>  endif
>  
> +# always use the host compiler
> +ifneq ($(LLVM),)
> +HOSTAR  ?= llvm-ar
> +HOSTCC  ?= clang
> +HOSTLD  ?= ld.lld
> +else
> +HOSTAR  ?= ar
> +HOSTCC  ?= gcc
> +HOSTLD  ?= ld
> +endif
> +AR       = $(HOSTAR)
> +CC       = $(HOSTCC)
> +LD       = $(HOSTLD)
> +
>  OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
>  
>  LIBBPF_SRC := $(srctree)/tools/lib/bpf/
> 

Thanks for the quick response.  However, in the mean time the bpf-next
tree has been merged into the net-next tree, so these fixes will be
needed there ASAP.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2020-07-14  9:00 ` Jiri Olsa
@ 2020-07-14  9:27   ` Geert Uytterhoeven
  2020-07-14 10:33   ` Stephen Rothwell
  1 sibling, 0 replies; 46+ messages in thread
From: Geert Uytterhoeven @ 2020-07-14  9:27 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov,
	Networking, Linux Next Mailing List, Linux Kernel Mailing List,
	Jiri Olsa

On Tue, Jul 14, 2020 at 11:02 AM Jiri Olsa <jolsa@redhat.com> wrote:
> On Tue, Jul 14, 2020 at 12:16:08PM +1000, Stephen Rothwell wrote:
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
> > ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
> >
> > Presumably ntroduced by the merge of the resolve_btfids branch.
>
> missing one more #ifdef.. chage below fixes it for me,
> it's squashed with the fix for the arm build, I'll post
> both fixes today

This one works for me, too:
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  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
  0 siblings, 2 replies; 46+ messages in thread
From: Jiri Olsa @ 2020-07-14  9:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List, Jiri Olsa

On Tue, Jul 14, 2020 at 12:16:08PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
> ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
> 
> Presumably ntroduced by the merge of the resolve_btfids branch.

missing one more #ifdef.. chage below fixes it for me,
it's squashed with the fix for the arm build, I'll post 
both fixes today

thanks,
jirka


---
diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
index fe019774f8a7..2f9754a4ab2b 100644
--- a/include/linux/btf_ids.h
+++ b/include/linux/btf_ids.h
@@ -3,6 +3,8 @@
 #ifndef _LINUX_BTF_IDS_H
 #define _LINUX_BTF_IDS_H
 
+#ifdef CONFIG_DEBUG_INFO_BTF
+
 #include <linux/compiler.h> /* for __PASTE */
 
 /*
@@ -21,7 +23,7 @@
 asm(							\
 ".pushsection " BTF_IDS_SECTION ",\"a\";       \n"	\
 ".local " #symbol " ;                          \n"	\
-".type  " #symbol ", @object;                  \n"	\
+".type  " #symbol ", STT_OBJECT;               \n"	\
 ".size  " #symbol ", 4;                        \n"	\
 #symbol ":                                     \n"	\
 ".zero 4                                       \n"	\
@@ -83,5 +85,12 @@ asm(							\
 ".zero 4                                       \n"	\
 ".popsection;                                  \n");
 
+#else
+
+#define BTF_ID_LIST(name) u32 name[5];
+#define BTF_ID(prefix, name)
+#define BTF_ID_UNUSED
+
+#endif /* CONFIG_DEBUG_INFO_BTF */
 
 #endif
diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
index 948378ca73d4..a88cd4426398 100644
--- a/tools/bpf/resolve_btfids/Makefile
+++ b/tools/bpf/resolve_btfids/Makefile
@@ -16,6 +16,20 @@ else
   MAKEFLAGS=--no-print-directory
 endif
 
+# always use the host compiler
+ifneq ($(LLVM),)
+HOSTAR  ?= llvm-ar
+HOSTCC  ?= clang
+HOSTLD  ?= ld.lld
+else
+HOSTAR  ?= ar
+HOSTCC  ?= gcc
+HOSTLD  ?= ld
+endif
+AR       = $(HOSTAR)
+CC       = $(HOSTCC)
+LD       = $(HOSTLD)
+
 OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
 
 LIBBPF_SRC := $(srctree)/tools/lib/bpf/


^ permalink raw reply	[flat|nested] 46+ messages in thread

* linux-next: build warning after merge of the bpf-next tree
@ 2020-07-14  2:16 Stephen Rothwell
  2020-07-14  9:00 ` Jiri Olsa
  0 siblings, 1 reply; 46+ messages in thread
From: Stephen Rothwell @ 2020-07-14  2:16 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jiri Olsa

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `kernel/trace/bpf_trace.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `kernel/bpf/btf.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `kernel/bpf/stackmap.o' being placed in section `.BTF_ids'
ld: warning: orphan section `.BTF_ids' from `net/core/filter.o' being placed in section `.BTF_ids'

Presumably ntroduced by the merge of the resolve_btfids branch.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* Re: linux-next: build warning after merge of the bpf-next tree
  2019-03-24 22:28 Stephen Rothwell
@ 2019-03-24 22:39 ` Willem de Bruijn
  0 siblings, 0 replies; 46+ messages in thread
From: Willem de Bruijn @ 2019-03-24 22:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Willem de Bruijn, David Miller

On Sun, Mar 24, 2019 at 6:30 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> net/core/filter.c: In function 'bpf_skb_adjust_room':
> net/core/filter.c:3022:31: warning: 'inner_trans' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    skb->inner_transport_header = inner_trans;
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
> net/core/filter.c:2979:26: note: 'inner_trans' was declared here
>   u16 mac_len, inner_net, inner_trans;
>                           ^~~~~~~~~~~
> net/core/filter.c:3021:29: warning: 'inner_net' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    skb->inner_network_header = inner_net;
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> net/core/filter.c:2979:15: note: 'inner_net' was declared here
>   u16 mac_len, inner_net, inner_trans;
>                ^~~~~~~~~
> net/core/filter.c:3026:3: warning: 'mac_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    skb_set_network_header(skb, mac_len);
>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> net/core/filter.c:2979:6: note: 'mac_len' was declared here
>   u16 mac_len, inner_net, inner_trans;
>       ^~~~~~~
>
> Introduced by commit
>
>   868d523535c2 ("bpf: add bpf_skb_adjust_room encap flags")
>
>
> This looks like a false positive, it seems that they are only set and
> used when encap is true.

Indeed. Sorry about that.

The fix for this is now in bpf-next, commit 62b31b42cff9 ("bpf:
silence uninitialized var warning in bpf_skb_net_grow").

^ permalink raw reply	[flat|nested] 46+ messages in thread

* linux-next: build warning after merge of the bpf-next tree
@ 2019-03-24 22:28 Stephen Rothwell
  2019-03-24 22:39 ` Willem de Bruijn
  0 siblings, 1 reply; 46+ messages in thread
From: Stephen Rothwell @ 2019-03-24 22:28 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Willem de Bruijn, David Miller

[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

net/core/filter.c: In function 'bpf_skb_adjust_room':
net/core/filter.c:3022:31: warning: 'inner_trans' may be used uninitialized in this function [-Wmaybe-uninitialized]
   skb->inner_transport_header = inner_trans;
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
net/core/filter.c:2979:26: note: 'inner_trans' was declared here
  u16 mac_len, inner_net, inner_trans;
                          ^~~~~~~~~~~
net/core/filter.c:3021:29: warning: 'inner_net' may be used uninitialized in this function [-Wmaybe-uninitialized]
   skb->inner_network_header = inner_net;
   ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
net/core/filter.c:2979:15: note: 'inner_net' was declared here
  u16 mac_len, inner_net, inner_trans;
               ^~~~~~~~~
net/core/filter.c:3026:3: warning: 'mac_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
   skb_set_network_header(skb, mac_len);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/core/filter.c:2979:6: note: 'mac_len' was declared here
  u16 mac_len, inner_net, inner_trans;
      ^~~~~~~

Introduced by commit

  868d523535c2 ("bpf: add bpf_skb_adjust_room encap flags")


This looks like a false positive, it seems that they are only set and
used when encap is true.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

* linux-next: build warning after merge of the bpf-next tree
@ 2018-05-09  4:49 Stephen Rothwell
  0 siblings, 0 replies; 46+ messages in thread
From: Stephen Rothwell @ 2018-05-09  4:49 UTC (permalink / raw)
  To: Daniel Borkmann, Alexei Starovoitov, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Ahern

[-- Attachment #1: Type: text/plain, Size: 2854 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/dma-mapping.h:5:0,
                 from include/linux/skbuff.h:34,
                 from include/linux/if_ether.h:23,
                 from include/uapi/linux/bpf.h:13,
                 from include/linux/bpf-cgroup.h:6,
                 from include/linux/cgroup-defs.h:22,
                 from include/linux/cgroup.h:28,
                 from include/linux/perf_event.h:57,
                 from include/linux/trace_events.h:10,
                 from include/trace/trace_events.h:20,
                 from include/trace/define_trace.h:96,
                 from drivers/android/binder_trace.h:387,
                 from drivers/android/binder.c:5702:
include/linux/sizes.h:24:0: warning: "SZ_1K" redefined
 #define SZ_1K    0x00000400
drivers/android/binder.c:116:0: note: this is the location of the previous definition
 #define SZ_1K                               0x400
In file included from include/linux/dma-mapping.h:5:0,
                 from include/linux/skbuff.h:34,
                 from include/linux/if_ether.h:23,
                 from include/uapi/linux/bpf.h:13,
                 from include/linux/bpf-cgroup.h:6,
                 from include/linux/cgroup-defs.h:22,
                 from include/linux/cgroup.h:28,
                 from include/linux/perf_event.h:57,
                 from include/linux/trace_events.h:10,
                 from include/trace/trace_events.h:20,
                 from include/trace/define_trace.h:96,
                 from drivers/android/binder_trace.h:387,
                 from drivers/android/binder.c:5702:
include/linux/sizes.h:37:0: warning: "SZ_4M" redefined
 #define SZ_4M    0x00400000
drivers/android/binder.c:120:0: note: this is the location of the previous definition
 #define SZ_4M                               0x400000
fs/ecryptfs/miscdev.c:206:0: warning: "PKT_TYPE_OFFSET" redefined
 #define PKT_TYPE_OFFSET  0
In file included from include/linux/if_ether.h:23:0,
                 from include/uapi/linux/bpf.h:13,
                 from include/linux/bpf-cgroup.h:6,
                 from include/linux/cgroup-defs.h:22,
                 from include/linux/cgroup.h:28,
                 from include/linux/writeback.h:183,
                 from include/linux/backing-dev.h:16,
                 from fs/ecryptfs/ecryptfs_kernel.h:41,
                 from fs/ecryptfs/miscdev.c:30:
include/linux/skbuff.h:753:0: note: this is the location of the previous definition
 #define PKT_TYPE_OFFSET() offsetof(struct sk_buff, __pkt_type_offset)

Introduced by commit

  9c38f3c8b153 ("bpf: Provide helper to do forwarding lookups in kernel FIB table")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 46+ messages in thread

end of thread, other threads:[~2021-12-07  3:23 UTC | newest]

Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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 --
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

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.