[+lkml, Masahiro, Alexei and Daniel]
On Tue, Nov 12, 2019 at 04:56:39PM +0800, Xiao Yang wrote:
> With your patch[1], I alway get the following error when building
> tools/bpf:
In case people want to reproduce this, my branch is here:
https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
> ----------------------------------------------------------------------------------
>
> make -C tools/bpf/
> make: Entering directory
> '/usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf'
>
> Auto-detecting system features:
> ... libbfd: [ on ]
> ... disassembler-four-args: [ OFF ]
>
> CC bpf_jit_disasm.o
> CC bpf_dbg.o
> In file included from
> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/uapi/linux/filter.h:9:0,
> from
> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf/bpf_dbg.c:41:
> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/linux/compiler.h:247:24:
> fatal error: asm/rwonce.h: No such file or directory
> #include <asm/rwonce.h>
> ^
> compilation terminated.
> Makefile:61: recipe for target 'bpf_dbg.o' failed
> make: *** [bpf_dbg.o] Error 1
> make: *** Waiting for unfinished jobs....
> make: Leaving directory
>
> ----------------------------------------------------------------------------------
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=lto&id=642a312d47ceb54603630d9d04f5052f3b46d9a3
>
> It seems that include/linux/compiler.h cannot find the asm/rwonce.h because
> tools/bpf/Makefile doesn't include arch/*/include/generated/asm/rwonce.h.
The problem with referring to the generated files is that they don't exist
unless you've configured the main source directory. The real problem here
seems to be that tools/bpf/ refers directly to header files in the kernel
sources without any understanding of kbuild, and therefore mandatory-y
headers simply don't exist when it goes looking for them.
Perhaps it's possible to introduce a dependency on a top-level "make
asm-generic" so that we can reference the generated headers from the arch
directly. Thoughts?
Will
On Tue, Nov 12, 2019 at 9:31 PM Will Deacon <[email protected]> wrote:
>
> [+lkml, Masahiro, Alexei and Daniel]
>
> On Tue, Nov 12, 2019 at 04:56:39PM +0800, Xiao Yang wrote:
> > With your patch[1], I alway get the following error when building
> > tools/bpf:
>
> In case people want to reproduce this, my branch is here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
>
> > ----------------------------------------------------------------------------------
> >
> > make -C tools/bpf/
> > make: Entering directory
> > '/usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf'
> >
> > Auto-detecting system features:
> > ... libbfd: [ on ]
> > ... disassembler-four-args: [ OFF ]
> >
> > CC bpf_jit_disasm.o
> > CC bpf_dbg.o
> > In file included from
> > /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/uapi/linux/filter.h:9:0,
> > from
> > /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf/bpf_dbg.c:41:
> > /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/linux/compiler.h:247:24:
> > fatal error: asm/rwonce.h: No such file or directory
> > #include <asm/rwonce.h>
> > ^
> > compilation terminated.
> > Makefile:61: recipe for target 'bpf_dbg.o' failed
> > make: *** [bpf_dbg.o] Error 1
> > make: *** Waiting for unfinished jobs....
> > make: Leaving directory
> >
> > ----------------------------------------------------------------------------------
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=lto&id=642a312d47ceb54603630d9d04f5052f3b46d9a3
> >
> > It seems that include/linux/compiler.h cannot find the asm/rwonce.h because
> > tools/bpf/Makefile doesn't include arch/*/include/generated/asm/rwonce.h.
>
> The problem with referring to the generated files is that they don't exist
> unless you've configured the main source directory. The real problem here
> seems to be that tools/bpf/ refers directly to header files in the kernel
> sources without any understanding of kbuild, and therefore mandatory-y
> headers simply don't exist when it goes looking for them.
Please note tools/ is out of scope of Kbuild.
The tools/ created a completely different build system.
tools/bpf/ looks like a host program.
Does it include a kernel-space header
of the target architecture?
I see a lots of header duplication in tools/include/,
but I am not sure if
tools/include/linux/filter.h is the correct header
to include.
>
> Perhaps it's possible to introduce a dependency on a top-level "make
> asm-generic" so that we can reference the generated headers from the arch
> directly. Thoughts?
>
> Will
--
Best Regards
Masahiro Yamada
On 11/12/19 1:50 PM, Masahiro Yamada wrote:
> On Tue, Nov 12, 2019 at 9:31 PM Will Deacon <[email protected]> wrote:
>>
>> [+lkml, Masahiro, Alexei and Daniel]
>>
>> On Tue, Nov 12, 2019 at 04:56:39PM +0800, Xiao Yang wrote:
>>> With your patch[1], I alway get the following error when building
>>> tools/bpf:
>>
>> In case people want to reproduce this, my branch is here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
>>
>>> ----------------------------------------------------------------------------------
>>>
>>> make -C tools/bpf/
>>> make: Entering directory
>>> '/usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf'
>>>
>>> Auto-detecting system features:
>>> ... libbfd: [ on ]
>>> ... disassembler-four-args: [ OFF ]
>>>
>>> CC bpf_jit_disasm.o
>>> CC bpf_dbg.o
>>> In file included from
>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/uapi/linux/filter.h:9:0,
>>> from
>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf/bpf_dbg.c:41:
>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/linux/compiler.h:247:24:
>>> fatal error: asm/rwonce.h: No such file or directory
>>> #include <asm/rwonce.h>
>>> ^
>>> compilation terminated.
>>> Makefile:61: recipe for target 'bpf_dbg.o' failed
>>> make: *** [bpf_dbg.o] Error 1
>>> make: *** Waiting for unfinished jobs....
>>> make: Leaving directory
>>>
>>> ----------------------------------------------------------------------------------
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=lto&id=642a312d47ceb54603630d9d04f5052f3b46d9a3
>>>
>>> It seems that include/linux/compiler.h cannot find the asm/rwonce.h because
>>> tools/bpf/Makefile doesn't include arch/*/include/generated/asm/rwonce.h.
>>
>> The problem with referring to the generated files is that they don't exist
>> unless you've configured the main source directory. The real problem here
>> seems to be that tools/bpf/ refers directly to header files in the kernel
>> sources without any understanding of kbuild, and therefore mandatory-y
>> headers simply don't exist when it goes looking for them.
Hmm, I am puzzled why that is. :/ I think there are two options, i) remove it
from CFLAGS like below (at least this doesn't let the build fail in my case
but requires linux headers to be installed) or ii) add a copy of filter.h to
tools/include/uapi/linux/filter.h so the few tools can just reuse it. We do have
bpf_common.h and bpf.h there already.
diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
index 5d1995fd369c..08dfd289174c 100644
--- a/tools/bpf/Makefile
+++ b/tools/bpf/Makefile
@@ -10,7 +10,6 @@ MAKE = make
INSTALL ?= install
CFLAGS += -Wall -O2
-CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi -I$(srctree)/include
# This will work when bpf is built in tools env. where srctree
# isn't set and when invoked from selftests build, where srctree
Thanks,
Daniel
On 11/12/19 8:31 PM, Will Deacon wrote:
> [+lkml, Masahiro, Alexei and Daniel]
>
> On Tue, Nov 12, 2019 at 04:56:39PM +0800, Xiao Yang wrote:
>> With your patch[1], I alway get the following error when building
>> tools/bpf:
> In case people want to reproduce this, my branch is here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
>
>> ----------------------------------------------------------------------------------
>>
>> make -C tools/bpf/
>> make: Entering directory
>> '/usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf'
>>
>> Auto-detecting system features:
>> ... libbfd: [ on ]
>> ... disassembler-four-args: [ OFF ]
>>
>> CC bpf_jit_disasm.o
>> CC bpf_dbg.o
>> In file included from
>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/uapi/linux/filter.h:9:0,
>> from
>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf/bpf_dbg.c:41:
>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/linux/compiler.h:247:24:
>> fatal error: asm/rwonce.h: No such file or directory
>> #include <asm/rwonce.h>
>> ^
>> compilation terminated.
>> Makefile:61: recipe for target 'bpf_dbg.o' failed
>> make: *** [bpf_dbg.o] Error 1
>> make: *** Waiting for unfinished jobs....
>> make: Leaving directory
>>
>> ----------------------------------------------------------------------------------
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=lto&id=642a312d47ceb54603630d9d04f5052f3b46d9a3
>>
>> It seems that include/linux/compiler.h cannot find the asm/rwonce.h because
>> tools/bpf/Makefile doesn't include arch/*/include/generated/asm/rwonce.h.
> The problem with referring to the generated files is that they don't exist
> unless you've configured the main source directory. The real problem here
> seems to be that tools/bpf/ refers directly to header files in the kernel
> sources without any understanding of kbuild, and therefore mandatory-y
> headers simply don't exist when it goes looking for them.
>
> Perhaps it's possible to introduce a dependency on a top-level "make
> asm-generic" so that we can reference the generated headers from the arch
> directly. Thoughts?
Hi Will,
Thanks for your reply.
I tried to do "make asm-generic" operation before, but it just generated
asm/rwonce.h
in arch/*/include/generated directory and building tools/bpf still
cannot find it.
Perhaps, the Makefile of tools/bpf needs to be improved.
Best Regards,
Xiao Yang
>
> Will
On 11/12/19 11:13 PM, Daniel Borkmann wrote:
> On 11/12/19 1:50 PM, Masahiro Yamada wrote:
>> On Tue, Nov 12, 2019 at 9:31 PM Will Deacon <[email protected]> wrote:
>>>
>>> [+lkml, Masahiro, Alexei and Daniel]
>>>
>>> On Tue, Nov 12, 2019 at 04:56:39PM +0800, Xiao Yang wrote:
>>>> With your patch[1], I alway get the following error when building
>>>> tools/bpf:
>>>
>>> In case people want to reproduce this, my branch is here:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
>>>
>>>
>>>> ----------------------------------------------------------------------------------
>>>>
>>>>
>>>> make -C tools/bpf/
>>>> make: Entering directory
>>>> '/usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf'
>>>>
>>>>
>>>> Auto-detecting system features:
>>>> ... libbfd: [ on ]
>>>> ... disassembler-four-args: [ OFF ]
>>>>
>>>> CC bpf_jit_disasm.o
>>>> CC bpf_dbg.o
>>>> In file included from
>>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/uapi/linux/filter.h:9:0,
>>>>
>>>> from
>>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf/bpf_dbg.c:41:
>>>>
>>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/linux/compiler.h:247:24:
>>>>
>>>> fatal error: asm/rwonce.h: No such file or directory
>>>> #include <asm/rwonce.h>
>>>> ^
>>>> compilation terminated.
>>>> Makefile:61: recipe for target 'bpf_dbg.o' failed
>>>> make: *** [bpf_dbg.o] Error 1
>>>> make: *** Waiting for unfinished jobs....
>>>> make: Leaving directory
>>>>
>>>> ----------------------------------------------------------------------------------
>>>>
>>>>
>>>> [1]
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=lto&id=642a312d47ceb54603630d9d04f5052f3b46d9a3
>>>>
>>>> It seems that include/linux/compiler.h cannot find the asm/rwonce.h
>>>> because
>>>> tools/bpf/Makefile doesn't include
>>>> arch/*/include/generated/asm/rwonce.h.
>>>
>>> The problem with referring to the generated files is that they don't
>>> exist
>>> unless you've configured the main source directory. The real problem
>>> here
>>> seems to be that tools/bpf/ refers directly to header files in the
>>> kernel
>>> sources without any understanding of kbuild, and therefore mandatory-y
>>> headers simply don't exist when it goes looking for them.
>
> Hmm, I am puzzled why that is. :/ I think there are two options, i)
> remove it
> from CFLAGS like below (at least this doesn't let the build fail in my
> case
> but requires linux headers to be installed) or ii) add a copy of
> filter.h to
> tools/include/uapi/linux/filter.h so the few tools can just reuse it.
> We do have
> bpf_common.h and bpf.h there already.
Hi Daniel,
Thanks for your suggestions.
Did you mean that building bpf uses the filter.h from installed linux
header rather than include/uapi/linux/filter.h in kernel?
It seems that you just try to workaround the issue by using
linux/filter.h from linux header.
The root casue is that include/linux/compiler.h cannot find the location
of <asm/rwonce.h>.
Thanks,
Xiao Yang
>
> diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
> index 5d1995fd369c..08dfd289174c 100644
> --- a/tools/bpf/Makefile
> +++ b/tools/bpf/Makefile
> @@ -10,7 +10,6 @@ MAKE = make
> INSTALL ?= install
>
> CFLAGS += -Wall -O2
> -CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi
> -I$(srctree)/include
>
> # This will work when bpf is built in tools env. where srctree
> # isn't set and when invoked from selftests build, where srctree
>
> Thanks,
> Daniel
On Wed, Nov 13, 2019 at 12:13 AM Daniel Borkmann <[email protected]> wrote:
>
> On 11/12/19 1:50 PM, Masahiro Yamada wrote:
> > On Tue, Nov 12, 2019 at 9:31 PM Will Deacon <[email protected]> wrote:
> >>
> >> [+lkml, Masahiro, Alexei and Daniel]
> >>
> >> On Tue, Nov 12, 2019 at 04:56:39PM +0800, Xiao Yang wrote:
> >>> With your patch[1], I alway get the following error when building
> >>> tools/bpf:
> >>
> >> In case people want to reproduce this, my branch is here:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
> >>
> >>> ----------------------------------------------------------------------------------
> >>>
> >>> make -C tools/bpf/
> >>> make: Entering directory
> >>> '/usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf'
> >>>
> >>> Auto-detecting system features:
> >>> ... libbfd: [ on ]
> >>> ... disassembler-four-args: [ OFF ]
> >>>
> >>> CC bpf_jit_disasm.o
> >>> CC bpf_dbg.o
> >>> In file included from
> >>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/uapi/linux/filter.h:9:0,
> >>> from
> >>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf/bpf_dbg.c:41:
> >>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/linux/compiler.h:247:24:
> >>> fatal error: asm/rwonce.h: No such file or directory
> >>> #include <asm/rwonce.h>
> >>> ^
> >>> compilation terminated.
> >>> Makefile:61: recipe for target 'bpf_dbg.o' failed
> >>> make: *** [bpf_dbg.o] Error 1
> >>> make: *** Waiting for unfinished jobs....
> >>> make: Leaving directory
> >>>
> >>> ----------------------------------------------------------------------------------
> >>>
> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=lto&id=642a312d47ceb54603630d9d04f5052f3b46d9a3
> >>>
> >>> It seems that include/linux/compiler.h cannot find the asm/rwonce.h because
> >>> tools/bpf/Makefile doesn't include arch/*/include/generated/asm/rwonce.h.
> >>
> >> The problem with referring to the generated files is that they don't exist
> >> unless you've configured the main source directory. The real problem here
> >> seems to be that tools/bpf/ refers directly to header files in the kernel
> >> sources without any understanding of kbuild, and therefore mandatory-y
> >> headers simply don't exist when it goes looking for them.
>
> Hmm, I am puzzled why that is. :/ I think there are two options, i) remove it
> from CFLAGS like below (at least this doesn't let the build fail in my case
> but requires linux headers to be installed) or ii) add a copy of filter.h to
> tools/include/uapi/linux/filter.h so the few tools can just reuse it. We do have
> bpf_common.h and bpf.h there already.
>
> diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
> index 5d1995fd369c..08dfd289174c 100644
> --- a/tools/bpf/Makefile
> +++ b/tools/bpf/Makefile
> @@ -10,7 +10,6 @@ MAKE = make
> INSTALL ?= install
>
> CFLAGS += -Wall -O2
> -CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi -I$(srctree)/include
>
> # This will work when bpf is built in tools env. where srctree
> # isn't set and when invoked from selftests build, where srctree
>
I think this is the most sane fix
to include the linux/filter.h in the system.
(probably, it is located in /usr/include/linux/filter.h)
--
Best Regards
Masahiro Yamada
On 11/13/19 1:28 PM, Masahiro Yamada wrote:
> On Wed, Nov 13, 2019 at 12:13 AM Daniel Borkmann <[email protected]> wrote:
>> On 11/12/19 1:50 PM, Masahiro Yamada wrote:
>>> On Tue, Nov 12, 2019 at 9:31 PM Will Deacon <[email protected]> wrote:
>>>> [+lkml, Masahiro, Alexei and Daniel]
>>>>
>>>> On Tue, Nov 12, 2019 at 04:56:39PM +0800, Xiao Yang wrote:
>>>>> With your patch[1], I alway get the following error when building
>>>>> tools/bpf:
>>>> In case people want to reproduce this, my branch is here:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
>>>>
>>>>> ----------------------------------------------------------------------------------
>>>>>
>>>>> make -C tools/bpf/
>>>>> make: Entering directory
>>>>> '/usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf'
>>>>>
>>>>> Auto-detecting system features:
>>>>> ... libbfd: [ on ]
>>>>> ... disassembler-four-args: [ OFF ]
>>>>>
>>>>> CC bpf_jit_disasm.o
>>>>> CC bpf_dbg.o
>>>>> In file included from
>>>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/uapi/linux/filter.h:9:0,
>>>>> from
>>>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf/bpf_dbg.c:41:
>>>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/linux/compiler.h:247:24:
>>>>> fatal error: asm/rwonce.h: No such file or directory
>>>>> #include <asm/rwonce.h>
>>>>> ^
>>>>> compilation terminated.
>>>>> Makefile:61: recipe for target 'bpf_dbg.o' failed
>>>>> make: *** [bpf_dbg.o] Error 1
>>>>> make: *** Waiting for unfinished jobs....
>>>>> make: Leaving directory
>>>>>
>>>>> ----------------------------------------------------------------------------------
>>>>>
>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=lto&id=642a312d47ceb54603630d9d04f5052f3b46d9a3
>>>>>
>>>>> It seems that include/linux/compiler.h cannot find the asm/rwonce.h because
>>>>> tools/bpf/Makefile doesn't include arch/*/include/generated/asm/rwonce.h.
>>>> The problem with referring to the generated files is that they don't exist
>>>> unless you've configured the main source directory. The real problem here
>>>> seems to be that tools/bpf/ refers directly to header files in the kernel
>>>> sources without any understanding of kbuild, and therefore mandatory-y
>>>> headers simply don't exist when it goes looking for them.
>> Hmm, I am puzzled why that is. :/ I think there are two options, i) remove it
>> from CFLAGS like below (at least this doesn't let the build fail in my case
>> but requires linux headers to be installed) or ii) add a copy of filter.h to
>> tools/include/uapi/linux/filter.h so the few tools can just reuse it. We do have
>> bpf_common.h and bpf.h there already.
>>
>> diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
>> index 5d1995fd369c..08dfd289174c 100644
>> --- a/tools/bpf/Makefile
>> +++ b/tools/bpf/Makefile
>> @@ -10,7 +10,6 @@ MAKE = make
>> INSTALL ?= install
>>
>> CFLAGS += -Wall -O2
>> -CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi -I$(srctree)/include
>>
>> # This will work when bpf is built in tools env. where srctree
>> # isn't set and when invoked from selftests build, where srctree
>>
>
> I think this is the most sane fix
> to include the linux/filter.h in the system.
>
> (probably, it is located in /usr/include/linux/filter.h)
Hi Masahiro,
Is it correct for include/linux/compiler.h to include <asm/rwonce.h>?
On x86_64 arch, asm/rwonce.h is generated in
./arch/x86/include/generated/ directory and compiler.h cannot find it.
Best Regards,
XIao Yang
>
>
On Wed, Nov 13, 2019 at 2:52 PM Xiao Yang <[email protected]> wrote:
>
> On 11/13/19 1:28 PM, Masahiro Yamada wrote:
> > On Wed, Nov 13, 2019 at 12:13 AM Daniel Borkmann <[email protected]> wrote:
> >> On 11/12/19 1:50 PM, Masahiro Yamada wrote:
> >>> On Tue, Nov 12, 2019 at 9:31 PM Will Deacon <[email protected]> wrote:
> >>>> [+lkml, Masahiro, Alexei and Daniel]
> >>>>
> >>>> On Tue, Nov 12, 2019 at 04:56:39PM +0800, Xiao Yang wrote:
> >>>>> With your patch[1], I alway get the following error when building
> >>>>> tools/bpf:
> >>>> In case people want to reproduce this, my branch is here:
> >>>>
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
> >>>>
> >>>>> ----------------------------------------------------------------------------------
> >>>>>
> >>>>> make -C tools/bpf/
> >>>>> make: Entering directory
> >>>>> '/usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf'
> >>>>>
> >>>>> Auto-detecting system features:
> >>>>> ... libbfd: [ on ]
> >>>>> ... disassembler-four-args: [ OFF ]
> >>>>>
> >>>>> CC bpf_jit_disasm.o
> >>>>> CC bpf_dbg.o
> >>>>> In file included from
> >>>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/uapi/linux/filter.h:9:0,
> >>>>> from
> >>>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/tools/bpf/bpf_dbg.c:41:
> >>>>> /usr/src/perf_selftests-x86_64-rhel-7.6-642a312d47ceb54603630d9d04f5052f3b46d9a3/include/linux/compiler.h:247:24:
> >>>>> fatal error: asm/rwonce.h: No such file or directory
> >>>>> #include <asm/rwonce.h>
> >>>>> ^
> >>>>> compilation terminated.
> >>>>> Makefile:61: recipe for target 'bpf_dbg.o' failed
> >>>>> make: *** [bpf_dbg.o] Error 1
> >>>>> make: *** Waiting for unfinished jobs....
> >>>>> make: Leaving directory
> >>>>>
> >>>>> ----------------------------------------------------------------------------------
> >>>>>
> >>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=lto&id=642a312d47ceb54603630d9d04f5052f3b46d9a3
> >>>>>
> >>>>> It seems that include/linux/compiler.h cannot find the asm/rwonce.h because
> >>>>> tools/bpf/Makefile doesn't include arch/*/include/generated/asm/rwonce.h.
> >>>> The problem with referring to the generated files is that they don't exist
> >>>> unless you've configured the main source directory. The real problem here
> >>>> seems to be that tools/bpf/ refers directly to header files in the kernel
> >>>> sources without any understanding of kbuild, and therefore mandatory-y
> >>>> headers simply don't exist when it goes looking for them.
> >> Hmm, I am puzzled why that is. :/ I think there are two options, i) remove it
> >> from CFLAGS like below (at least this doesn't let the build fail in my case
> >> but requires linux headers to be installed) or ii) add a copy of filter.h to
> >> tools/include/uapi/linux/filter.h so the few tools can just reuse it. We do have
> >> bpf_common.h and bpf.h there already.
> >>
> >> diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
> >> index 5d1995fd369c..08dfd289174c 100644
> >> --- a/tools/bpf/Makefile
> >> +++ b/tools/bpf/Makefile
> >> @@ -10,7 +10,6 @@ MAKE = make
> >> INSTALL ?= install
> >>
> >> CFLAGS += -Wall -O2
> >> -CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi -I$(srctree)/include
> >>
> >> # This will work when bpf is built in tools env. where srctree
> >> # isn't set and when invoked from selftests build, where srctree
> >>
> >
> > I think this is the most sane fix
> > to include the linux/filter.h in the system.
> >
> > (probably, it is located in /usr/include/linux/filter.h)
>
> Hi Masahiro,
>
> Is it correct for include/linux/compiler.h to include <asm/rwonce.h>?
Sorry, I really do not understand what you are doing.
include/linux/compiler.h is only for kernel-space.
Shrug if a user-land program includes it.
> On x86_64 arch, asm/rwonce.h is generated in
> ./arch/x86/include/generated/ directory and compiler.h cannot find it.
>
> Best Regards,
>
> XIao Yang
>
> >
> >
>
--
Best Regards
Masahiro Yamada
On 11/13/19 2:57 PM, Masahiro Yamada wrote:
> Sorry, I really do not understand what you are doing.
>
> include/linux/compiler.h is only for kernel-space.
> Shrug if a user-land program includes it.
Hi Masahiro,
For building tools/bpf, it is good to fix the compiler error by Daniel's
patch(i.e. use linux/filter from linux header).
linux/compiler.h may be used by other code in kernel. Is it possible to
trigger the same error when the other code
including linux/compiler.h is built? Is this kind of code able to find
the location of <asm/rwonce.h>?
Best Regards,
Xiao Yang
On Wed, Nov 13, 2019 at 4:17 PM Xiao Yang <[email protected]> wrote:
>
> On 11/13/19 2:57 PM, Masahiro Yamada wrote:
> > Sorry, I really do not understand what you are doing.
> >
> > include/linux/compiler.h is only for kernel-space.
> > Shrug if a user-land program includes it.
>
> Hi Masahiro,
>
> For building tools/bpf, it is good to fix the compiler error by Daniel's
> patch(i.e. use linux/filter from linux header).
>
> linux/compiler.h may be used by other code in kernel. Is it possible to
> trigger the same error when the other code
>
> including linux/compiler.h is built? Is this kind of code able to find
> the location of <asm/rwonce.h>?
<asm/rwonce.h> is also kernel-only header.
The kernel code can find <asm/rwonce.h>, but user-land code cannot.
> Best Regards,
>
> Xiao Yang
>
>
--
Best Regards
Masahiro Yamada
On 11/13/19 3:53 PM, Masahiro Yamada wrote:
> On Wed, Nov 13, 2019 at 4:17 PM Xiao Yang <[email protected]> wrote:
>> On 11/13/19 2:57 PM, Masahiro Yamada wrote:
>>> Sorry, I really do not understand what you are doing.
>>>
>>> include/linux/compiler.h is only for kernel-space.
>>> Shrug if a user-land program includes it.
>> Hi Masahiro,
>>
>> For building tools/bpf, it is good to fix the compiler error by Daniel's
>> patch(i.e. use linux/filter from linux header).
>>
>> linux/compiler.h may be used by other code in kernel. Is it possible to
>> trigger the same error when the other code
>>
>> including linux/compiler.h is built? Is this kind of code able to find
>> the location of <asm/rwonce.h>?
>
> <asm/rwonce.h> is also kernel-only header.
>
> The kernel code can find <asm/rwonce.h>, but user-land code cannot.
Hi Masahiro,
Sorry, I am not familar with it.
Thanks a lot for your explanation and I have seen the LINUXINCLUDE
variable in Makefile.
I will try to send a patch as Daniel suggested.
Best Regards,
Xiao Yang
>
>
>
>
>> Best Regards,
>>
>> Xiao Yang
>>
>>
>
On Wed, Nov 13, 2019 at 5:36 PM Xiao Yang <[email protected]> wrote:
>
> On 11/13/19 3:53 PM, Masahiro Yamada wrote:
> > On Wed, Nov 13, 2019 at 4:17 PM Xiao Yang <[email protected]> wrote:
> >> On 11/13/19 2:57 PM, Masahiro Yamada wrote:
> >>> Sorry, I really do not understand what you are doing.
> >>>
> >>> include/linux/compiler.h is only for kernel-space.
> >>> Shrug if a user-land program includes it.
> >> Hi Masahiro,
> >>
> >> For building tools/bpf, it is good to fix the compiler error by Daniel's
> >> patch(i.e. use linux/filter from linux header).
> >>
> >> linux/compiler.h may be used by other code in kernel. Is it possible to
> >> trigger the same error when the other code
> >>
> >> including linux/compiler.h is built? Is this kind of code able to find
> >> the location of <asm/rwonce.h>?
> >
> > <asm/rwonce.h> is also kernel-only header.
> >
> > The kernel code can find <asm/rwonce.h>, but user-land code cannot.
>
> Hi Masahiro,
>
> Sorry, I am not familar with it.
>
> Thanks a lot for your explanation and I have seen the LINUXINCLUDE
> variable in Makefile.
>
> I will try to send a patch as Daniel suggested.
>
> Best Regards,
>
> Xiao Yang
>
Hmm, digging into the git history,
this include path was added by the following commit:
commit d7475de58575c904818efa369c82e88c6648ce2e
Author: Kamal Mostafa <[email protected]>
Date: Wed Nov 11 14:24:27 2015 -0800
tools/net: Use include/uapi with __EXPORTED_HEADERS__
Use the local uapi headers to keep in sync with "recently" added #define's
(e.g. SKF_AD_VLAN_TPID). Refactored CFLAGS, and bpf_asm doesn't need -I.
Fixes: 3f356385e8a4 ("filter: bpf_asm: add minimal bpf asm tool")
Signed-off-by: Kamal Mostafa <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
I am not sure how big a deal it is,
but it could be a problem on old distros??
--
Best Regards
Masahiro Yamada
On 11/13/19 4:54 PM, Masahiro Yamada wrote:
> On Wed, Nov 13, 2019 at 5:36 PM Xiao Yang <[email protected]> wrote:
>> On 11/13/19 3:53 PM, Masahiro Yamada wrote:
>>> On Wed, Nov 13, 2019 at 4:17 PM Xiao Yang <[email protected]> wrote:
>>>> On 11/13/19 2:57 PM, Masahiro Yamada wrote:
>>>>> Sorry, I really do not understand what you are doing.
>>>>>
>>>>> include/linux/compiler.h is only for kernel-space.
>>>>> Shrug if a user-land program includes it.
>>>> Hi Masahiro,
>>>>
>>>> For building tools/bpf, it is good to fix the compiler error by Daniel's
>>>> patch(i.e. use linux/filter from linux header).
>>>>
>>>> linux/compiler.h may be used by other code in kernel. Is it possible to
>>>> trigger the same error when the other code
>>>>
>>>> including linux/compiler.h is built? Is this kind of code able to find
>>>> the location of <asm/rwonce.h>?
>>> <asm/rwonce.h> is also kernel-only header.
>>>
>>> The kernel code can find <asm/rwonce.h>, but user-land code cannot.
>> Hi Masahiro,
>>
>> Sorry, I am not familar with it.
>>
>> Thanks a lot for your explanation and I have seen the LINUXINCLUDE
>> variable in Makefile.
>>
>> I will try to send a patch as Daniel suggested.
>>
>> Best Regards,
>>
>> Xiao Yang
>>
> Hmm, digging into the git history,
> this include path was added by the following commit:
>
>
> commit d7475de58575c904818efa369c82e88c6648ce2e
> Author: Kamal Mostafa <[email protected]>
> Date: Wed Nov 11 14:24:27 2015 -0800
>
> tools/net: Use include/uapi with __EXPORTED_HEADERS__
>
> Use the local uapi headers to keep in sync with "recently" added #define's
> (e.g. SKF_AD_VLAN_TPID). Refactored CFLAGS, and bpf_asm doesn't need -I.
>
> Fixes: 3f356385e8a4 ("filter: bpf_asm: add minimal bpf asm tool")
> Signed-off-by: Kamal Mostafa <[email protected]>
> Acked-by: Daniel Borkmann <[email protected]>
> Signed-off-by: David S. Miller <[email protected]>
>
>
>
> I am not sure how big a deal it is,
> but it could be a problem on old distros??
>
Hi Daniel, Masahiro
Could we include the linux/filter.h generated by "make headers_install"
as a higher priority?
(PS: According to above commit, just ensure that tools/bpf keeps in sync
with new linux header as far as possible).
and then use the linux/filter.h in system if kernel doesn't provide
linux/filter.h by "make headers_install".
--------------------------------------------------------------------------------------------------------------------
diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
index 5d1995fd369c..1e0c768132af 100644
--- a/tools/bpf/Makefile
+++ b/tools/bpf/Makefile
@@ -10,7 +10,7 @@ MAKE = make
INSTALL ?= install
CFLAGS += -Wall -O2
-CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi
-I$(srctree)/include
+CFLAGS += -I$(srctree)/usr/include
# This will work when bpf is built in tools env. where srctree
# isn't set and when invoked from selftests build, where srctree
---------------------------------------------------------------------------------------------------------------------
Best Regards,
Xiao Yang
>
On Wed, Nov 13, 2019 at 11:57 PM Xiao Yang <[email protected]> wrote:
>
> On 11/13/19 4:54 PM, Masahiro Yamada wrote:
> > On Wed, Nov 13, 2019 at 5:36 PM Xiao Yang <[email protected]> wrote:
> >> On 11/13/19 3:53 PM, Masahiro Yamada wrote:
> >>> On Wed, Nov 13, 2019 at 4:17 PM Xiao Yang <[email protected]> wrote:
> >>>> On 11/13/19 2:57 PM, Masahiro Yamada wrote:
> >>>>> Sorry, I really do not understand what you are doing.
> >>>>>
> >>>>> include/linux/compiler.h is only for kernel-space.
> >>>>> Shrug if a user-land program includes it.
> >>>> Hi Masahiro,
> >>>>
> >>>> For building tools/bpf, it is good to fix the compiler error by Daniel's
> >>>> patch(i.e. use linux/filter from linux header).
> >>>>
> >>>> linux/compiler.h may be used by other code in kernel. Is it possible to
> >>>> trigger the same error when the other code
> >>>>
> >>>> including linux/compiler.h is built? Is this kind of code able to find
> >>>> the location of <asm/rwonce.h>?
> >>> <asm/rwonce.h> is also kernel-only header.
> >>>
> >>> The kernel code can find <asm/rwonce.h>, but user-land code cannot.
> >> Hi Masahiro,
> >>
> >> Sorry, I am not familar with it.
> >>
> >> Thanks a lot for your explanation and I have seen the LINUXINCLUDE
> >> variable in Makefile.
> >>
> >> I will try to send a patch as Daniel suggested.
> >>
> >> Best Regards,
> >>
> >> Xiao Yang
> >>
> > Hmm, digging into the git history,
> > this include path was added by the following commit:
> >
> >
> > commit d7475de58575c904818efa369c82e88c6648ce2e
> > Author: Kamal Mostafa <[email protected]>
> > Date: Wed Nov 11 14:24:27 2015 -0800
> >
> > tools/net: Use include/uapi with __EXPORTED_HEADERS__
> >
> > Use the local uapi headers to keep in sync with "recently" added #define's
> > (e.g. SKF_AD_VLAN_TPID). Refactored CFLAGS, and bpf_asm doesn't need -I.
> >
> > Fixes: 3f356385e8a4 ("filter: bpf_asm: add minimal bpf asm tool")
> > Signed-off-by: Kamal Mostafa <[email protected]>
> > Acked-by: Daniel Borkmann <[email protected]>
> > Signed-off-by: David S. Miller <[email protected]>
> >
> >
> >
> > I am not sure how big a deal it is,
> > but it could be a problem on old distros??
> >
> Hi Daniel, Masahiro
>
>
> Could we include the linux/filter.h generated by "make headers_install"
> as a higher priority?
>
> (PS: According to above commit, just ensure that tools/bpf keeps in sync
> with new linux header as far as possible).
>
> and then use the linux/filter.h in system if kernel doesn't provide
> linux/filter.h by "make headers_install".
>
> --------------------------------------------------------------------------------------------------------------------
>
> diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
> index 5d1995fd369c..1e0c768132af 100644
> --- a/tools/bpf/Makefile
> +++ b/tools/bpf/Makefile
> @@ -10,7 +10,7 @@ MAKE = make
> INSTALL ?= install
>
> CFLAGS += -Wall -O2
> -CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi
> -I$(srctree)/include
> +CFLAGS += -I$(srctree)/usr/include
Probably, this does not work for O= build.
And, you also need to run 'make headers' somewhere
because usr/include does not contain any header in a clean state.
Be careful, people always tend to break out-of-tree build.
I recommend to double, triple check it.
(I believe this is a horrible design mistake
of the tools build system.)
> # This will work when bpf is built in tools env. where srctree
> # isn't set and when invoked from selftests build, where srctree
>
> ---------------------------------------------------------------------------------------------------------------------
>
>
> Best Regards,
>
> Xiao Yang
>
> >
>
--
Best Regards
Masahiro Yamada