From: Stephen Rothwell <hidden> Date: 2020-08-21 01:11:21
Hi all,
After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Auto-detecting system features:
... libelf: [ [31mOFF[m ]
... zlib: [ [31mOFF[m ]
... bpf: [ [32mon[m ]
No libelf found
make[5]: *** [Makefile:284: elfdep] Error 1
Caused by commit
d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")
[For a start, can we please *not* add this verbose feature detection
output to the nrormal build?]
This is a PowerPC hosted cross build.
I have marked BPF_PRELOAD as BROKEN for now.
--
Cheers,
Stephen Rothwell
From: Stephen Rothwell <hidden> Date: 2020-08-25 01:20:28
Hi all,
On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell [off-list ref] wrote:
Hi all,
After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Auto-detecting system features:
... libelf: [ [31mOFF[m ]
... zlib: [ [31mOFF[m ]
... bpf: [ [32mon[m ]
No libelf found
make[5]: *** [Makefile:284: elfdep] Error 1
Caused by commit
d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")
[For a start, can we please *not* add this verbose feature detection
output to the nrormal build?]
This is a PowerPC hosted cross build.
I have marked BPF_PRELOAD as BROKEN for now.
Still getting this failure ...
--
Cheers,
Stephen Rothwell
On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell [off-list ref] wrote:
Hi all,
On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell [off-list ref] wrote:
quoted
Hi all,
After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Auto-detecting system features:
... libelf: [ [31mOFF [m ]
... zlib: [ [31mOFF [m ]
... bpf: [ [32mon [m ]
No libelf found
make[5]: *** [Makefile:284: elfdep] Error 1
Caused by commit
d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")
[For a start, can we please *not* add this verbose feature detection
output to the nrormal build?]
This is a PowerPC hosted cross build.
I have marked BPF_PRELOAD as BROKEN for now.
Still getting this failure ...
I don't have powerpc with crosscompiler to x86 to reproduce.
What exactly the error?
bpf_preload has:
"depends on CC_CAN_LINK"
which is exactly the same as bpfilter.
You should have seen this issue with bpfilter for years now.
From: Stephen Rothwell <hidden> Date: 2020-08-25 03:04:57
Hi Alexei,
On Mon, 24 Aug 2020 18:25:44 -0700 Alexei Starovoitov [off-list ref] wrote:
On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell [off-list ref] wrote:
quoted
On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell [off-list ref] wrote:
quoted
After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Auto-detecting system features:
... libelf: [ [31mOFF [m ]
... zlib: [ [31mOFF [m ]
... bpf: [ [32mon [m ]
No libelf found
make[5]: *** [Makefile:284: elfdep] Error 1
Caused by commit
d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")
[For a start, can we please *not* add this verbose feature detection
output to the nrormal build?]
This is a PowerPC hosted cross build.
I have marked BPF_PRELOAD as BROKEN for now.
Still getting this failure ...
I don't have powerpc with crosscompiler to x86 to reproduce.
What exactly the error?
Just as above.
bpf_preload has:
"depends on CC_CAN_LINK"
which is exactly the same as bpfilter.
You should have seen this issue with bpfilter for years now.
Well, I haven't :-) It just started the other day when that commit
appeared.
--
Cheers,
Stephen Rothwell
On Mon, Aug 24, 2020 at 8:04 PM Stephen Rothwell [off-list ref] wrote:
Hi Alexei,
On Mon, 24 Aug 2020 18:25:44 -0700 Alexei Starovoitov [off-list ref] wrote:
quoted
On Mon, Aug 24, 2020 at 6:20 PM Stephen Rothwell [off-list ref] wrote:
quoted
On Fri, 21 Aug 2020 11:11:11 +1000 Stephen Rothwell [off-list ref] wrote:
quoted
After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Auto-detecting system features:
... libelf: [ [31mOFF [m ]
... zlib: [ [31mOFF [m ]
... bpf: [ [32mon [m ]
No libelf found
make[5]: *** [Makefile:284: elfdep] Error 1
Caused by commit
d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")
[For a start, can we please *not* add this verbose feature detection
output to the nrormal build?]
This is a PowerPC hosted cross build.
I have marked BPF_PRELOAD as BROKEN for now.
Still getting this failure ...
I don't have powerpc with crosscompiler to x86 to reproduce.
What exactly the error?
Just as above.
I didn't receive the first email you've replied to.
The build error is:
"
No libelf found
make[5]: *** [Makefile:284: elfdep] Error 1
"
and build process stops because libelf is not found, right?
That is expected and necessary.
bpf_preload needs libbpf that depends on libelf.
The only 'fix' is to turn off bpf_preload.
It's off by default.
allmodconfig cannot build bpf_preload umd if there is no libelf.
There is CC_CAN_LINK that does feature detection.
We can extend scripts/cc-can-link.sh or add another script that
will do CC_CAN_LINK_LIBELF, but such approach doesn't scale.
imo it's cleaner to rely on feature detection by libbpf Makefile with
an error above instead of adding such knobs to top Kconfig.
Does it make sense?
From: Stephen Rothwell <hidden> Date: 2020-08-25 06:50:42
Hi Alexei,
On Mon, 24 Aug 2020 20:27:28 -0700 Alexei Starovoitov [off-list ref] wrote:
I didn't receive the first email you've replied to.
The build error is:
"
No libelf found
make[5]: *** [Makefile:284: elfdep] Error 1
"
and build process stops because libelf is not found, right?
That is expected and necessary.
bpf_preload needs libbpf that depends on libelf.
The only 'fix' is to turn off bpf_preload.
It's off by default.
allmodconfig cannot build bpf_preload umd if there is no libelf.
There is CC_CAN_LINK that does feature detection.
We can extend scripts/cc-can-link.sh or add another script that
will do CC_CAN_LINK_LIBELF, but such approach doesn't scale.
imo it's cleaner to rely on feature detection by libbpf Makefile with
an error above instead of adding such knobs to top Kconfig.
Does it make sense?
Sorry, but if this is not necessary to build the kernel, then an
allmodconfig build needs to succeed so you need to do the detection and
turn it off automatically. Or you could make it so that it has to be
manually enabled in all circumstances.
--
Cheers,
Stephen Rothwell
On Mon, Aug 24, 2020 at 11:50 PM Stephen Rothwell [off-list ref] wrote:
Hi Alexei,
On Mon, 24 Aug 2020 20:27:28 -0700 Alexei Starovoitov [off-list ref] wrote:
quoted
I didn't receive the first email you've replied to.
The build error is:
"
No libelf found
make[5]: *** [Makefile:284: elfdep] Error 1
"
and build process stops because libelf is not found, right?
That is expected and necessary.
bpf_preload needs libbpf that depends on libelf.
The only 'fix' is to turn off bpf_preload.
It's off by default.
allmodconfig cannot build bpf_preload umd if there is no libelf.
There is CC_CAN_LINK that does feature detection.
We can extend scripts/cc-can-link.sh or add another script that
will do CC_CAN_LINK_LIBELF, but such approach doesn't scale.
imo it's cleaner to rely on feature detection by libbpf Makefile with
an error above instead of adding such knobs to top Kconfig.
Does it make sense?
Sorry, but if this is not necessary to build the kernel, then an
allmodconfig build needs to succeed so you need to do the detection and
turn it off automatically. Or you could make it so that it has to be
manually enabled in all circumstances.
what do you suggest to use to make it 'manually enabled' ?
All I could think of is to add:
depends on !COMPILE_TEST
so that allmodconfig doesn't pick it up.
From: Stephen Rothwell <hidden> Date: 2020-08-25 21:10:53
Hi Alexei,
On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov [off-list ref] wrote:
what do you suggest to use to make it 'manually enabled' ?
All I could think of is to add:
depends on !COMPILE_TEST
so that allmodconfig doesn't pick it up.
That is probably sufficient. Some gcc plugins and kasan bits, etc use
just that.
--
Cheers,
Stephen Rothwell
On Tue, Aug 25, 2020 at 2:10 PM Stephen Rothwell [off-list ref] wrote:
Hi Alexei,
On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov [off-list ref] wrote:
quoted
what do you suggest to use to make it 'manually enabled' ?
All I could think of is to add:
depends on !COMPILE_TEST
so that allmodconfig doesn't pick it up.
That is probably sufficient. Some gcc plugins and kasan bits, etc use
just that.
From: Stephen Rothwell <hidden> Date: 2020-08-25 23:09:32
Hi Alexei,
On Tue, 25 Aug 2020 15:34:52 -0700 Alexei Starovoitov [off-list ref] wrote:
On Tue, Aug 25, 2020 at 2:10 PM Stephen Rothwell [off-list ref] wrote:
quoted
Hi Alexei,
On Tue, 25 Aug 2020 07:33:51 -0700 Alexei Starovoitov [off-list ref] wrote:
quoted
what do you suggest to use to make it 'manually enabled' ?
All I could think of is to add:
depends on !COMPILE_TEST
so that allmodconfig doesn't pick it up.
That is probably sufficient. Some gcc plugins and kasan bits, etc use
just that.