| Message ID | 20240325102055.1037135-1-max.oss.09@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v1,1/2] perf: fix build with latest kernel | expand |
On Mon, Mar 25, 2024 at 6:21 AM <max.oss.09@gmail.com> wrote: > From: Max Krummenacher <max.krummenacher@toradex.com> > > Kernel commit 9eea8fafe33e ("libbpf: fix __arg_ctx type enforcement for > perf_event programs") added with 6.9-rc1 > tools/include/uapi/asm/bpf_perf_event.h > which for arc, arm64, loongarch, riscv and s390 includes headers from > the arch/${ARCH}/... directories. > Thus the build in OE fails as those headers are not present. > > Fix this by additioanly copying all files in arch/${ARCH}/include/. > > Fixes: > ERROR: perf-1.0-r0 do_compile: oe_runmake failed > | In file included from > work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/linux/bpf_perf_event.h:11, > | from libbpf.c:36: > | > work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/asm/bpf_perf_event.h:2:10: > fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such > file or directory > | 2 | #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h" > | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> > --- > meta/recipes-kernel/perf/perf.bb | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/ > perf.bb > index 4f26813de0..6408c65462 100644 > --- a/meta/recipes-kernel/perf/perf.bb > +++ b/meta/recipes-kernel/perf/perf.bb > @@ -139,6 +139,7 @@ PERF_SRC ?= "Makefile \ > tools/scripts \ > scripts/ \ > arch/arm64/tools \ > + arch/${ARCH}/include \ > We've always tried to stay within the tools/ source umbrella since we really don't want to copy any more of the kernel than we have to, since otherwise, we might as well go back to simplifying things and just building against the entire kernel source tree. I'd like to see if there's a way that we could limit this to the uapi (and hence use our uapi headers), and avoid needing to make the copy. If we need a copy, then being as specific as possible would be the goal. I'm not moving linux-yocto-dev to the latest -dev until next week, but I can look into this more then. Bruce > arch/${ARCH}/Makefile \ > " > > -- > 2.42.0 > >
On Tue, Mar 26, 2024 at 1:46 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > On Mon, Mar 25, 2024 at 6:21 AM <max.oss.09@gmail.com> wrote: > >> From: Max Krummenacher <max.krummenacher@toradex.com> >> >> Kernel commit 9eea8fafe33e ("libbpf: fix __arg_ctx type enforcement for >> perf_event programs") added with 6.9-rc1 >> tools/include/uapi/asm/bpf_perf_event.h >> which for arc, arm64, loongarch, riscv and s390 includes headers from >> the arch/${ARCH}/... directories. >> Thus the build in OE fails as those headers are not present. >> >> Fix this by additioanly copying all files in arch/${ARCH}/include/. >> >> Fixes: >> ERROR: perf-1.0-r0 do_compile: oe_runmake failed >> | In file included from >> work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/linux/bpf_perf_event.h:11, >> | from libbpf.c:36: >> | >> work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/asm/bpf_perf_event.h:2:10: >> fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such >> file or directory >> | 2 | #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h" >> | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> >> --- >> meta/recipes-kernel/perf/perf.bb | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/ >> perf.bb >> index 4f26813de0..6408c65462 100644 >> --- a/meta/recipes-kernel/perf/perf.bb >> +++ b/meta/recipes-kernel/perf/perf.bb >> @@ -139,6 +139,7 @@ PERF_SRC ?= "Makefile \ >> tools/scripts \ >> scripts/ \ >> arch/arm64/tools \ >> + arch/${ARCH}/include \ >> > > We've always tried to stay within the tools/ source umbrella since we > really > don't want to copy any more of the kernel than we have to, since > otherwise, > we might as well go back to simplifying things and just building against > the > entire kernel source tree. > > I'd like to see if there's a way that we could limit this to the uapi (and > hence > use our uapi headers), and avoid needing to make the copy. If we need a > copy, then being as specific as possible would be the goal. > I meant to also add that I'm not talking about the libc-headers for the uapi bits, as they are not tracking the latest kernel by design. Although it would be interesting to see how perf does treat the older uapi against the new kernel, so we can document the tested combinations. Bruce > > I'm not moving linux-yocto-dev to the latest -dev until next week, but I > can > look into this more then. > > Bruce > > > >> arch/${ARCH}/Makefile \ >> " >> >> -- >> 2.42.0 >> >> > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await thee > at its end > - "Use the force Harry" - Gandalf, Star Trek II > >
On Tue, Mar 26, 2024 at 6:48 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > On Tue, Mar 26, 2024 at 1:46 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: >> >> >> >> On Mon, Mar 25, 2024 at 6:21 AM <max.oss.09@gmail.com> wrote: >>> >>> From: Max Krummenacher <max.krummenacher@toradex.com> >>> >>> Kernel commit 9eea8fafe33e ("libbpf: fix __arg_ctx type enforcement for >>> perf_event programs") added with 6.9-rc1 tools/include/uapi/asm/bpf_perf_event.h >>> which for arc, arm64, loongarch, riscv and s390 includes headers from >>> the arch/${ARCH}/... directories. >>> Thus the build in OE fails as those headers are not present. >>> >>> Fix this by additioanly copying all files in arch/${ARCH}/include/. >>> >>> Fixes: >>> ERROR: perf-1.0-r0 do_compile: oe_runmake failed >>> | In file included from work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/linux/bpf_perf_event.h:11, >>> | from libbpf.c:36: >>> | work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/asm/bpf_perf_event.h:2:10: fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such file or directory >>> | 2 | #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h" >>> | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> >>> --- >>> meta/recipes-kernel/perf/perf.bb | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb >>> index 4f26813de0..6408c65462 100644 >>> --- a/meta/recipes-kernel/perf/perf.bb >>> +++ b/meta/recipes-kernel/perf/perf.bb >>> @@ -139,6 +139,7 @@ PERF_SRC ?= "Makefile \ >>> tools/scripts \ >>> scripts/ \ >>> arch/arm64/tools \ >>> + arch/${ARCH}/include \ >> >> >> We've always tried to stay within the tools/ source umbrella since we really >> don't want to copy any more of the kernel than we have to, since otherwise, >> we might as well go back to simplifying things and just building against the >> entire kernel source tree. >> >> I'd like to see if there's a way that we could limit this to the uapi (and hence >> use our uapi headers), and avoid needing to make the copy. If we need a >> copy, then being as specific as possible would be the goal. I was too lazy to limit this when I came up with the patch. Currently the only header missing is ../../arch/arm64/include/uapi/asm/bpf_perf_event.h, so limiting to arch/${ARCH}/include/uapi should work fine, I'm unsure if the header file itself exists for every ${ARCH} so only copying the one file is probably a dangerous way forward. > > > > I meant to also add that I'm not talking about the libc-headers for the > uapi bits, as they are not tracking the latest kernel by design. Although > it would be interesting to see how perf does treat the older uapi against > the new kernel, so we can document the tested combinations. > > Bruce Let's wait till you give linux-yocto-dev a try run.Happy Easter. Max > > >> >> >> I'm not moving linux-yocto-dev to the latest -dev until next week, but I can >> look into this more then. >> >> Bruce >> >> >>> >>> arch/${ARCH}/Makefile \ >>> " >>> >>> -- >>> 2.42.0 >>> >> >> >> -- >> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end >> - "Use the force Harry" - Gandalf, Star Trek II >> > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end > - "Use the force Harry" - Gandalf, Star Trek II >
On Thu, Mar 28, 2024 at 1:55 PM Max Krummenacher <max.oss.09@gmail.com> wrote: > > On Tue, Mar 26, 2024 at 6:48 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > On Tue, Mar 26, 2024 at 1:46 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > >> > >> > >> > >> On Mon, Mar 25, 2024 at 6:21 AM <max.oss.09@gmail.com> wrote: > >>> > >>> From: Max Krummenacher <max.krummenacher@toradex.com> > >>> > >>> Kernel commit 9eea8fafe33e ("libbpf: fix __arg_ctx type enforcement for > >>> perf_event programs") added with 6.9-rc1 tools/include/uapi/asm/bpf_perf_event.h > >>> which for arc, arm64, loongarch, riscv and s390 includes headers from > >>> the arch/${ARCH}/... directories. > >>> Thus the build in OE fails as those headers are not present. > >>> > >>> Fix this by additioanly copying all files in arch/${ARCH}/include/. > >>> > >>> Fixes: > >>> ERROR: perf-1.0-r0 do_compile: oe_runmake failed > >>> | In file included from work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/linux/bpf_perf_event.h:11, > >>> | from libbpf.c:36: > >>> | work/verdin_imx8mm-tdx-linux/perf/1.0/perf-1.0/tools/include/uapi/asm/bpf_perf_event.h:2:10: fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such file or directory > >>> | 2 | #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h" > >>> | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> > >>> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> > >>> --- > >>> meta/recipes-kernel/perf/perf.bb | 1 + > >>> 1 file changed, 1 insertion(+) > >>> > >>> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb > >>> index 4f26813de0..6408c65462 100644 > >>> --- a/meta/recipes-kernel/perf/perf.bb > >>> +++ b/meta/recipes-kernel/perf/perf.bb > >>> @@ -139,6 +139,7 @@ PERF_SRC ?= "Makefile \ > >>> tools/scripts \ > >>> scripts/ \ > >>> arch/arm64/tools \ > >>> + arch/${ARCH}/include \ > >> > >> > >> We've always tried to stay within the tools/ source umbrella since we really > >> don't want to copy any more of the kernel than we have to, since otherwise, > >> we might as well go back to simplifying things and just building against the > >> entire kernel source tree. > >> > >> I'd like to see if there's a way that we could limit this to the uapi (and hence > >> use our uapi headers), and avoid needing to make the copy. If we need a > >> copy, then being as specific as possible would be the goal. > > I was too lazy to limit this when I came up with the patch. > Currently the only header missing is > ../../arch/arm64/include/uapi/asm/bpf_perf_event.h, > so limiting to arch/${ARCH}/include/uapi should work fine, I'm unsure if > the header file itself exists for every ${ARCH} so only copying the one > file is probably a dangerous way forward. > > > > > > > > > I meant to also add that I'm not talking about the libc-headers for the > > uapi bits, as they are not tracking the latest kernel by design. Although > > it would be interesting to see how perf does treat the older uapi against > > the new kernel, so we can document the tested combinations. > > > > Bruce > > Let's wait till you give linux-yocto-dev a try run.Happy Easter. I have linux-yocto-dev on 6.9-rc2 now. I have a few non-perf packages to fix before I can send it to the list, but to finish up this thread. I tested with your patch, as well as the finer grained included, and that does indeed fix the problem. At a minimum, we should go with the uapi as the include addition. I'm tempted to experiment with just the single file, and ensure that our source copy routines in perf can handle it. The reason why I'm focused on it, is that this is just temporary until I upgrade our libc-headers recipe in the next release cycle, after that, it should provide what is needed for perf and we'll have what is essentially an extra copy (although harmless). I agree that the best place for the perl dependency is on the -tests package, as I don't see big gains on creating a perl-tests package for the dependency .. since if it is used to process the other results, most everything would just have the dependency anyway. Bruce > Max > > > > > >> > >> > >> I'm not moving linux-yocto-dev to the latest -dev until next week, but I can > >> look into this more then. > >> > >> Bruce > >> > >> > >>> > >>> arch/${ARCH}/Makefile \ > >>> " > >>> > >>> -- > >>> 2.42.0 > >>> > >> > >> > >> -- > >> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end > >> - "Use the force Harry" - Gandalf, Star Trek II > >> > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > >
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb index 4f26813de0..6408c65462 100644 --- a/meta/recipes-kernel/perf/perf.bb +++ b/meta/recipes-kernel/perf/perf.bb @@ -139,6 +139,7 @@ PERF_SRC ?= "Makefile \ tools/scripts \ scripts/ \ arch/arm64/tools \ + arch/${ARCH}/include \ arch/${ARCH}/Makefile \ "