[v2,0/3] Assume libbpf 1.0+

Message ID	20230116010115.490713-1-irogers@google.com (mailing list archive)
Headers	show Return-Path: <bpf-owner@vger.kernel.org> Date: Sun, 15 Jan 2023 17:01:12 -0800 Message-Id: <20230116010115.490713-1-irogers@google.com> Mime-Version: 1.0 Subject: [PATCH v2 0/3] Assume libbpf 1.0+ From: Ian Rogers <irogers@google.com> To: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Andres Freund <andres@anarazel.de>, Quentin Monnet <quentin@isovalent.com>, Roberto Sassu <roberto.sassu@huawei.com>, Christy Lee <christylee@fb.com>, Andrii Nakryiko <andrii@kernel.org>, Adrian Hunter <adrian.hunter@intel.com>, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, bpf@vger.kernel.org Cc: Ian Rogers <irogers@google.com> Content-Type: text/plain; charset="UTF-8" Precedence: bulk
Series	Assume libbpf 1.0+ \| expand [v2,0/3] Assume libbpf 1.0+ [v2,1/3] tools build: Pass libbpf feature only if libbpf 1.0+ [v2,2/3] perf build: Remove libbpf pre-1.0 feature tests [v2,3/3] perf bpf: Remove pre libbpf 1.0 conditional logic

Ian Rogers Jan. 16, 2023, 1:01 a.m. UTC

libbpf 1.0 was a major change in API. Perf has partially supported
older libbpf's but an implementation may be:
..
       pr_err("%s: not support, update libbpf\n", __func__);
       return -ENOTSUP;
..

Rather than build a binary that would fail at runtime it is
preferrential just to build libbpf statically and link against
that. The static version is in the kernel tools tree and newer than
1.0.

These patches change the libbpf test to only pass when at least
version 1.0 is installed, then remove the conditional build and
feature logic.

The issue is discussed here:
https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
perf bpf:

A variant of this fix was added to Linux 6.2 in:
"perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
This change goes further in removing logic that is now no longer
necessary.

v2. Rebase now that breakage fix patch is in linus/master.

Ian Rogers (3):
  tools build: Pass libbpf feature only if libbpf 1.0+
  perf build: Remove libbpf pre-1.0 feature tests
  perf bpf: Remove pre libbpf 1.0 conditional logic

 tools/build/feature/Makefile                  |  7 --
 .../feature/test-libbpf-bpf_map_create.c      |  8 ---
 .../test-libbpf-bpf_object__next_map.c        |  8 ---
 .../test-libbpf-bpf_object__next_program.c    |  8 ---
 .../build/feature/test-libbpf-bpf_prog_load.c |  9 ---
 .../test-libbpf-bpf_program__set_insns.c      |  8 ---
 .../test-libbpf-btf__load_from_kernel_by_id.c |  8 ---
 .../build/feature/test-libbpf-btf__raw_data.c |  8 ---
 tools/build/feature/test-libbpf.c             |  4 ++
 tools/perf/Makefile.config                    | 39 +----------
 tools/perf/util/bpf-event.c                   | 66 -------------------
 tools/perf/util/bpf-loader.c                  | 18 -----
 tools/perf/util/bpf_counter.c                 | 18 -----
 13 files changed, 5 insertions(+), 204 deletions(-)
 delete mode 100644 tools/build/feature/test-libbpf-bpf_map_create.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_map.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_program.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_prog_load.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_program__set_insns.c
 delete mode 100644 tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
 delete mode 100644 tools/build/feature/test-libbpf-btf__raw_data.c

Ian Rogers Jan. 19, 2023, 5:11 p.m. UTC | #1

On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
>
> libbpf 1.0 was a major change in API. Perf has partially supported
> older libbpf's but an implementation may be:
> ..
>        pr_err("%s: not support, update libbpf\n", __func__);
>        return -ENOTSUP;
> ..
>
> Rather than build a binary that would fail at runtime it is
> preferrential just to build libbpf statically and link against
> that. The static version is in the kernel tools tree and newer than
> 1.0.
>
> These patches change the libbpf test to only pass when at least
> version 1.0 is installed, then remove the conditional build and
> feature logic.
>
> The issue is discussed here:
> https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> perf bpf:
>
> A variant of this fix was added to Linux 6.2 in:
> "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> This change goes further in removing logic that is now no longer
> necessary.
>
> v2. Rebase now that breakage fix patch is in linus/master.

I missed the:
Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
I believe we are waiting for package maintainer input.

Thanks,
Ian



> Ian Rogers (3):
>   tools build: Pass libbpf feature only if libbpf 1.0+
>   perf build: Remove libbpf pre-1.0 feature tests
>   perf bpf: Remove pre libbpf 1.0 conditional logic
>
>  tools/build/feature/Makefile                  |  7 --
>  .../feature/test-libbpf-bpf_map_create.c      |  8 ---
>  .../test-libbpf-bpf_object__next_map.c        |  8 ---
>  .../test-libbpf-bpf_object__next_program.c    |  8 ---
>  .../build/feature/test-libbpf-bpf_prog_load.c |  9 ---
>  .../test-libbpf-bpf_program__set_insns.c      |  8 ---
>  .../test-libbpf-btf__load_from_kernel_by_id.c |  8 ---
>  .../build/feature/test-libbpf-btf__raw_data.c |  8 ---
>  tools/build/feature/test-libbpf.c             |  4 ++
>  tools/perf/Makefile.config                    | 39 +----------
>  tools/perf/util/bpf-event.c                   | 66 -------------------
>  tools/perf/util/bpf-loader.c                  | 18 -----
>  tools/perf/util/bpf_counter.c                 | 18 -----
>  13 files changed, 5 insertions(+), 204 deletions(-)
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_map_create.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_map.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_program.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_prog_load.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_program__set_insns.c
>  delete mode 100644 tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
>  delete mode 100644 tools/build/feature/test-libbpf-btf__raw_data.c
>
> --
> 2.39.0.314.g84b9a713c41-goog
>

Arnaldo Carvalho de Melo Jan. 19, 2023, 5:41 p.m. UTC | #2

Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > libbpf 1.0 was a major change in API. Perf has partially supported
> > older libbpf's but an implementation may be:
> > ..
> >        pr_err("%s: not support, update libbpf\n", __func__);
> >        return -ENOTSUP;
> > ..
> >
> > Rather than build a binary that would fail at runtime it is
> > preferrential just to build libbpf statically and link against
> > that. The static version is in the kernel tools tree and newer than
> > 1.0.
> >
> > These patches change the libbpf test to only pass when at least
> > version 1.0 is installed, then remove the conditional build and
> > feature logic.
> >
> > The issue is discussed here:
> > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > perf bpf:
> >
> > A variant of this fix was added to Linux 6.2 in:
> > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > This change goes further in removing logic that is now no longer
> > necessary.
> >
> > v2. Rebase now that breakage fix patch is in linus/master.
> 
> I missed the:
> Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> I believe we are waiting for package maintainer input.

Yes, as fedora:37 still is at libbpf 0.8.0 :-\

This is what I have in the containers I test, sure, the older ones
already have NO_LIBBPF=1 and some will get this added, and some I still
need to ask for libbpf-devel (or the distro specific name, like
libbpf-dev):

[perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
[perfbuilder@five ~]$

[perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
debian/experimental/Dockerfile:	libbpf-dev \
fedora/35/Dockerfile:		   libtraceevent-devel libbpf-devel \
fedora/36/Dockerfile:		   libtraceevent-devel libbpf-devel \
fedora/37/Dockerfile:		   libtraceevent-devel libbpf-devel \
fedora/38/Dockerfile:		   libtraceevent-devel libbpf-devel \
fedora/rawhide/Dockerfile:	libtraceevent-devel libbpf-devel \
opensuse/tumbleweed/Dockerfile:	libbpf-devel libtraceevent-devel \
ubuntu/22.04/Dockerfile:	libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
ubuntu/22.10/Dockerfile:	libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
ubuntu/23.04/Dockerfile:	libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
[perfbuilder@five linux-perf-tools-build]$

In some cases it gets dragged on differently, like with clearlinux,
gentoo, archlinux, etc.

Anyway, just a data point, I'll check if I'm missing installing it
somewhere.

- Arnaldo

Arnaldo Carvalho de Melo Jan. 19, 2023, 5:47 p.m. UTC | #3

Em Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo escreveu:
> Anyway, just a data point, I'll check if I'm missing installing it
> somewhere.

Just asked for libbpf-dev to be installed on the debian:11 container:

[perfbuilder@five 11]$ dsh debian:11
$ bash
perfbuilder@589d1572e8cf:/$ ls -la /usr/lib/x86_64-linux-gnu/libbpf.so.0
lrwxrwxrwx. 1 root root 15 Jan 10  2021 /usr/lib/x86_64-linux-gnu/libbpf.so.0 -> libbpf.so.0.3.0
perfbuilder@589d1572e8cf:/$ dpkg -l | grep bpf
ii  libbpf-dev:amd64                   1:0.3-2                        amd64        eBPF helper library (development files)
ii  libbpf0:amd64                      1:0.3-2                        amd64        eBPF helper library (shared library)
ii  libpfm4:amd64                      4.11.1+git32-gd0b85fb-1        amd64        Library to program the performance monitoring events
perfbuilder@589d1572e8cf:/$

- Arnaldo

Ian Rogers Jan. 19, 2023, 6:12 p.m. UTC | #4

On Thu, Jan 19, 2023 at 9:47 AM Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
>
> Em Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Anyway, just a data point, I'll check if I'm missing installing it
> > somewhere.
>
> Just asked for libbpf-dev to be installed on the debian:11 container:
>
> [perfbuilder@five 11]$ dsh debian:11
> $ bash
> perfbuilder@589d1572e8cf:/$ ls -la /usr/lib/x86_64-linux-gnu/libbpf.so.0
> lrwxrwxrwx. 1 root root 15 Jan 10  2021 /usr/lib/x86_64-linux-gnu/libbpf.so.0 -> libbpf.so.0.3.0
> perfbuilder@589d1572e8cf:/$ dpkg -l | grep bpf
> ii  libbpf-dev:amd64                   1:0.3-2                        amd64        eBPF helper library (development files)
> ii  libbpf0:amd64                      1:0.3-2                        amd64        eBPF helper library (shared library)
> ii  libpfm4:amd64                      4.11.1+git32-gd0b85fb-1        amd64        Library to program the performance monitoring events
> perfbuilder@589d1572e8cf:/$
>
> - Arnaldo

Right, the old/ancient libbpf-s are gross, but Debian doesn't use
LIBBPF_DYNAMIC which also isn't a default build option. I guess we
could say there's some testing impact from this cleanup, but I'm not
sure we care.

Thanks,
Ian

Jiri Olsa Jan. 19, 2023, 9:13 p.m. UTC | #5

On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > older libbpf's but an implementation may be:
> > > ..
> > >        pr_err("%s: not support, update libbpf\n", __func__);
> > >        return -ENOTSUP;
> > > ..
> > >
> > > Rather than build a binary that would fail at runtime it is
> > > preferrential just to build libbpf statically and link against
> > > that. The static version is in the kernel tools tree and newer than
> > > 1.0.
> > >
> > > These patches change the libbpf test to only pass when at least
> > > version 1.0 is installed, then remove the conditional build and
> > > feature logic.
> > >
> > > The issue is discussed here:
> > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > perf bpf:
> > >
> > > A variant of this fix was added to Linux 6.2 in:
> > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > This change goes further in removing logic that is now no longer
> > > necessary.
> > >
> > > v2. Rebase now that breakage fix patch is in linus/master.
> > 
> > I missed the:
> > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > I believe we are waiting for package maintainer input.
> 
> Yes, as fedora:37 still is at libbpf 0.8.0 :-\

rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
for f38, so not sure how bad it'd be for f37

jirka

> 
> This is what I have in the containers I test, sure, the older ones
> already have NO_LIBBPF=1 and some will get this added, and some I still
> need to ask for libbpf-devel (or the distro specific name, like
> libbpf-dev):
> 
> [perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
> localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> [perfbuilder@five ~]$
> 
> [perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
> debian/experimental/Dockerfile:	libbpf-dev \
> fedora/35/Dockerfile:		   libtraceevent-devel libbpf-devel \
> fedora/36/Dockerfile:		   libtraceevent-devel libbpf-devel \
> fedora/37/Dockerfile:		   libtraceevent-devel libbpf-devel \
> fedora/38/Dockerfile:		   libtraceevent-devel libbpf-devel \
> fedora/rawhide/Dockerfile:	libtraceevent-devel libbpf-devel \
> opensuse/tumbleweed/Dockerfile:	libbpf-devel libtraceevent-devel \
> ubuntu/22.04/Dockerfile:	libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> ubuntu/22.10/Dockerfile:	libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> ubuntu/23.04/Dockerfile:	libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> [perfbuilder@five linux-perf-tools-build]$
> 
> In some cases it gets dragged on differently, like with clearlinux,
> gentoo, archlinux, etc.
> 
> Anyway, just a data point, I'll check if I'm missing installing it
> somewhere.
> 
> - Arnaldo

Ian Rogers March 9, 2023, 2:13 a.m. UTC | #6

On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> wrote:
>
> On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > older libbpf's but an implementation may be:
> > > > ..
> > > >        pr_err("%s: not support, update libbpf\n", __func__);
> > > >        return -ENOTSUP;
> > > > ..
> > > >
> > > > Rather than build a binary that would fail at runtime it is
> > > > preferrential just to build libbpf statically and link against
> > > > that. The static version is in the kernel tools tree and newer than
> > > > 1.0.
> > > >
> > > > These patches change the libbpf test to only pass when at least
> > > > version 1.0 is installed, then remove the conditional build and
> > > > feature logic.
> > > >
> > > > The issue is discussed here:
> > > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > > perf bpf:
> > > >
> > > > A variant of this fix was added to Linux 6.2 in:
> > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > > This change goes further in removing logic that is now no longer
> > > > necessary.
> > > >
> > > > v2. Rebase now that breakage fix patch is in linus/master.
> > >
> > > I missed the:
> > > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > > I believe we are waiting for package maintainer input.
> >
> > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
>
> rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> for f38, so not sure how bad it'd be for f37
>
> jirka

+Guilherme

We were looking for maintainer input on these changes, but there is no
update in over a month. Here is the original lore link:
https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
Should these changes land in perf-tools-next targeting Linux 6.4?

Thanks,
Ian

> >
> > This is what I have in the containers I test, sure, the older ones
> > already have NO_LIBBPF=1 and some will get this added, and some I still
> > need to ask for libbpf-devel (or the distro specific name, like
> > libbpf-dev):
> >
> > [perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
> > localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > [perfbuilder@five ~]$
> >
> > [perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
> > debian/experimental/Dockerfile:       libbpf-dev \
> > fedora/35/Dockerfile:            libtraceevent-devel libbpf-devel \
> > fedora/36/Dockerfile:            libtraceevent-devel libbpf-devel \
> > fedora/37/Dockerfile:            libtraceevent-devel libbpf-devel \
> > fedora/38/Dockerfile:            libtraceevent-devel libbpf-devel \
> > fedora/rawhide/Dockerfile:    libtraceevent-devel libbpf-devel \
> > opensuse/tumbleweed/Dockerfile:       libbpf-devel libtraceevent-devel \
> > ubuntu/22.04/Dockerfile:      libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > ubuntu/22.10/Dockerfile:      libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > ubuntu/23.04/Dockerfile:      libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > [perfbuilder@five linux-perf-tools-build]$
> >
> > In some cases it gets dragged on differently, like with clearlinux,
> > gentoo, archlinux, etc.
> >
> > Anyway, just a data point, I'll check if I'm missing installing it
> > somewhere.
> >
> > - Arnaldo

Guilherme Amadio March 9, 2023, 7:58 a.m. UTC | #7

On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > older libbpf's but an implementation may be:
> > > > > ..
> > > > >        pr_err("%s: not support, update libbpf\n", __func__);
> > > > >        return -ENOTSUP;
> > > > > ..
> > > > >
> > > > > Rather than build a binary that would fail at runtime it is
> > > > > preferrential just to build libbpf statically and link against
> > > > > that. The static version is in the kernel tools tree and newer than
> > > > > 1.0.
> > > > >
> > > > > These patches change the libbpf test to only pass when at least
> > > > > version 1.0 is installed, then remove the conditional build and
> > > > > feature logic.
> > > > >
> > > > > The issue is discussed here:
> > > > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > > > perf bpf:
> > > > >
> > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > > > This change goes further in removing logic that is now no longer
> > > > > necessary.
> > > > >
> > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > >
> > > > I missed the:
> > > > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > > > I believe we are waiting for package maintainer input.
> > >
> > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> >
> > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > for f38, so not sure how bad it'd be for f37
> >
> > jirka
> 
> +Guilherme
> 
> We were looking for maintainer input on these changes, but there is no
> update in over a month. Here is the original lore link:
> https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> Should these changes land in perf-tools-next targeting Linux 6.4?

Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.

Best regards,
-Guilherme

Andrii Nakryiko March 9, 2023, 5:24 p.m. UTC | #8

On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> wrote:
>
> On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > >
> > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > older libbpf's but an implementation may be:
> > > > > > ..
> > > > > >        pr_err("%s: not support, update libbpf\n", __func__);
> > > > > >        return -ENOTSUP;
> > > > > > ..
> > > > > >
> > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > preferrential just to build libbpf statically and link against
> > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > 1.0.
> > > > > >
> > > > > > These patches change the libbpf test to only pass when at least
> > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > feature logic.
> > > > > >
> > > > > > The issue is discussed here:
> > > > > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > > > > perf bpf:
> > > > > >
> > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > > > > This change goes further in removing logic that is now no longer
> > > > > > necessary.
> > > > > >
> > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > >
> > > > > I missed the:
> > > > > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > > > > I believe we are waiting for package maintainer input.
> > > >
> > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > >
> > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > for f38, so not sure how bad it'd be for f37
> > >
> > > jirka
> >
> > +Guilherme
> >
> > We were looking for maintainer input on these changes, but there is no
> > update in over a month. Here is the original lore link:
> > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > Should these changes land in perf-tools-next targeting Linux 6.4?
>
> Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
>

libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
semantics is not enforced, unless libbpf_set_strict_mode() is enabled.

So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
APIs that are in 1.0 (except newer one added later, but I'm not sure
perf needs any of the newer additions), and just stick to setting
libbpf_set_strict_mode() unconditionally.


> Best regards,
> -Guilherme
>

Ian Rogers March 10, 2023, 3:26 a.m. UTC | #9

On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> wrote:
> >
> > On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > > >
> > > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > > older libbpf's but an implementation may be:
> > > > > > > ..
> > > > > > >        pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > >        return -ENOTSUP;
> > > > > > > ..
> > > > > > >
> > > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > > preferrential just to build libbpf statically and link against
> > > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > > 1.0.
> > > > > > >
> > > > > > > These patches change the libbpf test to only pass when at least
> > > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > > feature logic.
> > > > > > >
> > > > > > > The issue is discussed here:
> > > > > > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > > > > > perf bpf:
> > > > > > >
> > > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > > > > > This change goes further in removing logic that is now no longer
> > > > > > > necessary.
> > > > > > >
> > > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > > >
> > > > > > I missed the:
> > > > > > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > > > > > I believe we are waiting for package maintainer input.
> > > > >
> > > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > > >
> > > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > > for f38, so not sure how bad it'd be for f37
> > > >
> > > > jirka
> > >
> > > +Guilherme
> > >
> > > We were looking for maintainer input on these changes, but there is no
> > > update in over a month. Here is the original lore link:
> > > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > > Should these changes land in perf-tools-next targeting Linux 6.4?
> >
> > Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> > a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> > stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
> >
>
> libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
> semantics is not enforced, unless libbpf_set_strict_mode() is enabled.
>
> So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
> APIs that are in 1.0 (except newer one added later, but I'm not sure
> perf needs any of the newer additions), and just stick to setting
> libbpf_set_strict_mode() unconditionally.

Thanks Andrii,

The default perf build is to build against tools/lib/bpf and
statically link libbpf in. This means by default we have the latest
libbpf 1.2. If any perf code has a dependency on 0.8 (we don't support
earlier) we need to #ifdef for it. Currently we have 7 feature tests
for libbpf, but perhaps there is some cruft that's carried forward.
The features are:
 - btf__load_from_kernel_by_id
 - bpf_prog_load
 - bpf_object__next_program
 - bpf_object__next_map
 - bpf_program__set_insns
 - btf__raw_data
 - bpf_map_create

The not present implementations look like:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/bpf-loader.c?h=perf-tools#n36
```
int bpf_program__set_insns(struct bpf_program *prog __maybe_unused,
  struct bpf_insn *new_insns __maybe_unused, size_t new_insn_cnt __maybe_unused)
{
pr_err("%s: not support, update libbpf\n", __func__);
return -ENOTSUP;
}

int libbpf_register_prog_handler(const char *sec __maybe_unused,
                                 enum bpf_prog_type prog_type __maybe_unused,
                                 enum bpf_attach_type exp_attach_type
__maybe_unused,
                                 const struct libbpf_prog_handler_opts
*opts __maybe_unused)
{
pr_err("%s: not support, update libbpf\n", __func__);
return -ENOTSUP;
}
```
This will basically mean that while you dynamically linked with libbpf
0.8 you are in all likelihood not going to get proper BPF support.
These changes up the version requirement to 1.0 and get rid entirely
of the feature tests - so no runtime failing implementations. If the
build determines at build time libbpf 1.0+ isn't present then it still
executes, switching from dynamic libbpf to the default static libbpf
that is at 1.2. As mentioned in this thread, distributions like Debian
use the default static linking of libbpf.

I'm not keen to hold on to the feature tests for the complexity that
they hold and their needlessly (as you can always statically link)
broken at runtime behavior. We could but my opinion is, let's not :-)

Thanks,
Ian

> > Best regards,
> > -Guilherme
> >

Jiri Olsa March 10, 2023, 9:09 a.m. UTC | #10

On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > older libbpf's but an implementation may be:
> > > > > ..
> > > > >        pr_err("%s: not support, update libbpf\n", __func__);
> > > > >        return -ENOTSUP;
> > > > > ..
> > > > >
> > > > > Rather than build a binary that would fail at runtime it is
> > > > > preferrential just to build libbpf statically and link against
> > > > > that. The static version is in the kernel tools tree and newer than
> > > > > 1.0.
> > > > >
> > > > > These patches change the libbpf test to only pass when at least
> > > > > version 1.0 is installed, then remove the conditional build and
> > > > > feature logic.
> > > > >
> > > > > The issue is discussed here:
> > > > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > > > perf bpf:
> > > > >
> > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > > > This change goes further in removing logic that is now no longer
> > > > > necessary.
> > > > >
> > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > >
> > > > I missed the:
> > > > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > > > I believe we are waiting for package maintainer input.
> > >
> > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> >
> > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > for f38, so not sure how bad it'd be for f37
> >
> > jirka
> 
> +Guilherme
> 
> We were looking for maintainer input on these changes, but there is no
> update in over a month. Here is the original lore link:
> https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> Should these changes land in perf-tools-next targeting Linux 6.4?

ugh, I did not include Justin :-\ sry

Justin,
we are trying to move perf to use libbpf 1.0 only, which is fine for fedora 38,
but fedora 37 is still on libbpf 0.8 (and it's not easy to do the bulk update)

would fedora 37 even get to sync 6.4 kernel/kernel-tools?

thanks,
jirka

> 
> Thanks,
> Ian
> 
> > >
> > > This is what I have in the containers I test, sure, the older ones
> > > already have NO_LIBBPF=1 and some will get this added, and some I still
> > > need to ask for libbpf-devel (or the distro specific name, like
> > > libbpf-dev):
> > >
> > > [perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
> > > localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > > localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > > localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > [perfbuilder@five ~]$
> > >
> > > [perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
> > > debian/experimental/Dockerfile:       libbpf-dev \
> > > fedora/35/Dockerfile:            libtraceevent-devel libbpf-devel \
> > > fedora/36/Dockerfile:            libtraceevent-devel libbpf-devel \
> > > fedora/37/Dockerfile:            libtraceevent-devel libbpf-devel \
> > > fedora/38/Dockerfile:            libtraceevent-devel libbpf-devel \
> > > fedora/rawhide/Dockerfile:    libtraceevent-devel libbpf-devel \
> > > opensuse/tumbleweed/Dockerfile:       libbpf-devel libtraceevent-devel \
> > > ubuntu/22.04/Dockerfile:      libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > ubuntu/22.10/Dockerfile:      libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > ubuntu/23.04/Dockerfile:      libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > [perfbuilder@five linux-perf-tools-build]$
> > >
> > > In some cases it gets dragged on differently, like with clearlinux,
> > > gentoo, archlinux, etc.
> > >
> > > Anyway, just a data point, I'll check if I'm missing installing it
> > > somewhere.
> > >
> > > - Arnaldo

Justin Forbes March 10, 2023, 2:08 p.m. UTC | #11

On Fri, Mar 10, 2023 at 3:09 AM Jiri Olsa <olsajiri@gmail.com> wrote:
>
> On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > >
> > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > older libbpf's but an implementation may be:
> > > > > > ..
> > > > > >        pr_err("%s: not support, update libbpf\n", __func__);
> > > > > >        return -ENOTSUP;
> > > > > > ..
> > > > > >
> > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > preferrential just to build libbpf statically and link against
> > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > 1.0.
> > > > > >
> > > > > > These patches change the libbpf test to only pass when at least
> > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > feature logic.
> > > > > >
> > > > > > The issue is discussed here:
> > > > > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > > > > perf bpf:
> > > > > >
> > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > > > > This change goes further in removing logic that is now no longer
> > > > > > necessary.
> > > > > >
> > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > >
> > > > > I missed the:
> > > > > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > > > > I believe we are waiting for package maintainer input.
> > > >
> > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > >
> > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > for f38, so not sure how bad it'd be for f37
> > >
> > > jirka
> >
> > +Guilherme
> >
> > We were looking for maintainer input on these changes, but there is no
> > update in over a month. Here is the original lore link:
> > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > Should these changes land in perf-tools-next targeting Linux 6.4?
>
> ugh, I did not include Justin :-\ sry
>
> Justin,
> we are trying to move perf to use libbpf 1.0 only, which is fine for fedora 38,
> but fedora 37 is still on libbpf 0.8 (and it's not easy to do the bulk update)
>
> would fedora 37 even get to sync 6.4 kernel/kernel-tools?

Yes, Fedora 37 will not EOL until November when F39 has been out for
30 days. It will certainly get 6.4, which should come out this summer.
We could probably do some hackish static link situation for Fedora 37
if necessary though.  It isn't idea, but we know it is short lived, so
I would be okay with making that work.

Justin

> thanks,
> jirka
>
> >
> > Thanks,
> > Ian
> >
> > > >
> > > > This is what I have in the containers I test, sure, the older ones
> > > > already have NO_LIBBPF=1 and some will get this added, and some I still
> > > > need to ask for libbpf-devel (or the distro specific name, like
> > > > libbpf-dev):
> > > >
> > > > [perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
> > > > localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > > localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > > localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > > > localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > > > localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > > localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > [perfbuilder@five ~]$
> > > >
> > > > [perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
> > > > debian/experimental/Dockerfile:       libbpf-dev \
> > > > fedora/35/Dockerfile:            libtraceevent-devel libbpf-devel \
> > > > fedora/36/Dockerfile:            libtraceevent-devel libbpf-devel \
> > > > fedora/37/Dockerfile:            libtraceevent-devel libbpf-devel \
> > > > fedora/38/Dockerfile:            libtraceevent-devel libbpf-devel \
> > > > fedora/rawhide/Dockerfile:    libtraceevent-devel libbpf-devel \
> > > > opensuse/tumbleweed/Dockerfile:       libbpf-devel libtraceevent-devel \
> > > > ubuntu/22.04/Dockerfile:      libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > > ubuntu/22.10/Dockerfile:      libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > > ubuntu/23.04/Dockerfile:      libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > > [perfbuilder@five linux-perf-tools-build]$
> > > >
> > > > In some cases it gets dragged on differently, like with clearlinux,
> > > > gentoo, archlinux, etc.
> > > >
> > > > Anyway, just a data point, I'll check if I'm missing installing it
> > > > somewhere.
> > > >
> > > > - Arnaldo
>

Andrii Nakryiko March 10, 2023, 8:22 p.m. UTC | #12

On Thu, Mar 9, 2023 at 7:26 PM Ian Rogers <irogers@google.com> wrote:
>
> On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> wrote:
> > >
> > > On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > > > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > > > >
> > > > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > > > older libbpf's but an implementation may be:
> > > > > > > > ..
> > > > > > > >        pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > > >        return -ENOTSUP;
> > > > > > > > ..
> > > > > > > >
> > > > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > > > preferrential just to build libbpf statically and link against
> > > > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > > > 1.0.
> > > > > > > >
> > > > > > > > These patches change the libbpf test to only pass when at least
> > > > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > > > feature logic.
> > > > > > > >
> > > > > > > > The issue is discussed here:
> > > > > > > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > > > > > > perf bpf:
> > > > > > > >
> > > > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > > > > > > This change goes further in removing logic that is now no longer
> > > > > > > > necessary.
> > > > > > > >
> > > > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > > > >
> > > > > > > I missed the:
> > > > > > > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > > > > > > I believe we are waiting for package maintainer input.
> > > > > >
> > > > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > > > >
> > > > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > > > for f38, so not sure how bad it'd be for f37
> > > > >
> > > > > jirka
> > > >
> > > > +Guilherme
> > > >
> > > > We were looking for maintainer input on these changes, but there is no
> > > > update in over a month. Here is the original lore link:
> > > > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > > > Should these changes land in perf-tools-next targeting Linux 6.4?
> > >
> > > Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> > > a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> > > stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
> > >
> >
> > libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
> > semantics is not enforced, unless libbpf_set_strict_mode() is enabled.
> >
> > So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
> > APIs that are in 1.0 (except newer one added later, but I'm not sure
> > perf needs any of the newer additions), and just stick to setting
> > libbpf_set_strict_mode() unconditionally.
>
> Thanks Andrii,
>

Full disclosure, I'm totally supporting the switch to v1.0+, just
trying to be helpful here from the standpoint of 0.x vs 1.x libbpf
transition. See below. I believe you can keep 0.8+ dependency and drop
all the legacy code completely.

But just take it as an information, and feel free to do whatever you
think is best with it.

> The default perf build is to build against tools/lib/bpf and
> statically link libbpf in. This means by default we have the latest
> libbpf 1.2. If any perf code has a dependency on 0.8 (we don't support
> earlier) we need to #ifdef for it. Currently we have 7 feature tests
> for libbpf, but perhaps there is some cruft that's carried forward.
> The features are:
>  - btf__load_from_kernel_by_id

v0.5 API

>  - bpf_prog_load
>  - bpf_object__next_program
>  - bpf_object__next_map

all three are v0.6 APIs

>  - bpf_program__set_insns

v0.8 API

>  - btf__raw_data
>  - bpf_map_create

both v0.6 API

>
> The not present implementations look like:
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/bpf-loader.c?h=perf-tools#n36
> ```
> int bpf_program__set_insns(struct bpf_program *prog __maybe_unused,
>   struct bpf_insn *new_insns __maybe_unused, size_t new_insn_cnt __maybe_unused)
> {
> pr_err("%s: not support, update libbpf\n", __func__);
> return -ENOTSUP;
> }
>
> int libbpf_register_prog_handler(const char *sec __maybe_unused,
>                                  enum bpf_prog_type prog_type __maybe_unused,
>                                  enum bpf_attach_type exp_attach_type
> __maybe_unused,
>                                  const struct libbpf_prog_handler_opts
> *opts __maybe_unused)
> {
> pr_err("%s: not support, update libbpf\n", __func__);
> return -ENOTSUP;
> }
> ```

both are v0.8 APIs

> This will basically mean that while you dynamically linked with libbpf
> 0.8 you are in all likelihood not going to get proper BPF support.
> These changes up the version requirement to 1.0 and get rid entirely
> of the feature tests - so no runtime failing implementations. If the

100% supportive on upgrade and dropping feature checks. My point is
that you don't need those feature checks with v0.8+ requirement.

The only difference between staying on v0.8+ vs going all the way to
v1.0+ would be that you have to keep libbpf_set_strict() call. In
v1.0+ it's a noop, so could be dropped.

> build determines at build time libbpf 1.0+ isn't present then it still
> executes, switching from dynamic libbpf to the default static libbpf
> that is at 1.2. As mentioned in this thread, distributions like Debian
> use the default static linking of libbpf.
>

oh, that's nice, good to know

> I'm not keen to hold on to the feature tests for the complexity that
> they hold and their needlessly (as you can always statically link)
> broken at runtime behavior. We could but my opinion is, let's not :-)

I've been consistently advocating for static linking with libbpf, so
100% support this.

>
> Thanks,
> Ian
>
> > > Best regards,
> > > -Guilherme
> > >

Ian Rogers March 12, 2023, 1 a.m. UTC | #13

On Fri, Mar 10, 2023 at 12:22 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Thu, Mar 9, 2023 at 7:26 PM Ian Rogers <irogers@google.com> wrote:
> >
> > On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> > >
> > > On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> wrote:
> > > >
> > > > On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > > > > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > > > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > > > > older libbpf's but an implementation may be:
> > > > > > > > > ..
> > > > > > > > >        pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > > > >        return -ENOTSUP;
> > > > > > > > > ..
> > > > > > > > >
> > > > > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > > > > preferrential just to build libbpf statically and link against
> > > > > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > > > > 1.0.
> > > > > > > > >
> > > > > > > > > These patches change the libbpf test to only pass when at least
> > > > > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > > > > feature logic.
> > > > > > > > >
> > > > > > > > > The issue is discussed here:
> > > > > > > > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > > > > > > > perf bpf:
> > > > > > > > >
> > > > > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > > > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > > > > > > > This change goes further in removing logic that is now no longer
> > > > > > > > > necessary.
> > > > > > > > >
> > > > > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > > > > >
> > > > > > > > I missed the:
> > > > > > > > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > > > > > > > I believe we are waiting for package maintainer input.
> > > > > > >
> > > > > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > > > > >
> > > > > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > > > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > > > > for f38, so not sure how bad it'd be for f37
> > > > > >
> > > > > > jirka
> > > > >
> > > > > +Guilherme
> > > > >
> > > > > We were looking for maintainer input on these changes, but there is no
> > > > > update in over a month. Here is the original lore link:
> > > > > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > > > > Should these changes land in perf-tools-next targeting Linux 6.4?
> > > >
> > > > Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> > > > a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> > > > stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
> > > >
> > >
> > > libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
> > > semantics is not enforced, unless libbpf_set_strict_mode() is enabled.
> > >
> > > So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
> > > APIs that are in 1.0 (except newer one added later, but I'm not sure
> > > perf needs any of the newer additions), and just stick to setting
> > > libbpf_set_strict_mode() unconditionally.
> >
> > Thanks Andrii,
> >
>
> Full disclosure, I'm totally supporting the switch to v1.0+, just
> trying to be helpful here from the standpoint of 0.x vs 1.x libbpf
> transition. See below. I believe you can keep 0.8+ dependency and drop
> all the legacy code completely.
>
> But just take it as an information, and feel free to do whatever you
> think is best with it.
>
> > The default perf build is to build against tools/lib/bpf and
> > statically link libbpf in. This means by default we have the latest
> > libbpf 1.2. If any perf code has a dependency on 0.8 (we don't support
> > earlier) we need to #ifdef for it. Currently we have 7 feature tests
> > for libbpf, but perhaps there is some cruft that's carried forward.
> > The features are:
> >  - btf__load_from_kernel_by_id
>
> v0.5 API
>
> >  - bpf_prog_load
> >  - bpf_object__next_program
> >  - bpf_object__next_map
>
> all three are v0.6 APIs
>
> >  - bpf_program__set_insns
>
> v0.8 API
>
> >  - btf__raw_data
> >  - bpf_map_create
>
> both v0.6 API
>
> >
> > The not present implementations look like:
> > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/bpf-loader.c?h=perf-tools#n36
> > ```
> > int bpf_program__set_insns(struct bpf_program *prog __maybe_unused,
> >   struct bpf_insn *new_insns __maybe_unused, size_t new_insn_cnt __maybe_unused)
> > {
> > pr_err("%s: not support, update libbpf\n", __func__);
> > return -ENOTSUP;
> > }
> >
> > int libbpf_register_prog_handler(const char *sec __maybe_unused,
> >                                  enum bpf_prog_type prog_type __maybe_unused,
> >                                  enum bpf_attach_type exp_attach_type
> > __maybe_unused,
> >                                  const struct libbpf_prog_handler_opts
> > *opts __maybe_unused)
> > {
> > pr_err("%s: not support, update libbpf\n", __func__);
> > return -ENOTSUP;
> > }
> > ```
>
> both are v0.8 APIs
>
> > This will basically mean that while you dynamically linked with libbpf
> > 0.8 you are in all likelihood not going to get proper BPF support.
> > These changes up the version requirement to 1.0 and get rid entirely
> > of the feature tests - so no runtime failing implementations. If the
>
> 100% supportive on upgrade and dropping feature checks. My point is
> that you don't need those feature checks with v0.8+ requirement.
>
> The only difference between staying on v0.8+ vs going all the way to
> v1.0+ would be that you have to keep libbpf_set_strict() call. In
> v1.0+ it's a noop, so could be dropped.
>
> > build determines at build time libbpf 1.0+ isn't present then it still
> > executes, switching from dynamic libbpf to the default static libbpf
> > that is at 1.2. As mentioned in this thread, distributions like Debian
> > use the default static linking of libbpf.
> >
>
> oh, that's nice, good to know
>
> > I'm not keen to hold on to the feature tests for the complexity that
> > they hold and their needlessly (as you can always statically link)
> > broken at runtime behavior. We could but my opinion is, let's not :-)
>
> I've been consistently advocating for static linking with libbpf, so
> 100% support this.

Right, so I think we should move forward with these patches. We also
have had non-API changes to support libbpf 1.0+ like:
https://lore.kernel.org/lkml/20221103045437.163510-4-irogers@google.com/
and I'm worried about the state of these with libbpf 0.8.

Thanks,
Ian

> >
> > Thanks,
> > Ian
> >
> > > > Best regards,
> > > > -Guilherme
> > > >

Jiri Olsa March 12, 2023, 9:51 a.m. UTC | #14

On Sat, Mar 11, 2023 at 05:00:01PM -0800, Ian Rogers wrote:
> On Fri, Mar 10, 2023 at 12:22 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Thu, Mar 9, 2023 at 7:26 PM Ian Rogers <irogers@google.com> wrote:
> > >
> > > On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
> > > <andrii.nakryiko@gmail.com> wrote:
> > > >
> > > > On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> wrote:
> > > > >
> > > > > On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > > > > > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > > > > > >
> > > > > > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> wrote:
> > > > > > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > > > > > older libbpf's but an implementation may be:
> > > > > > > > > > ..
> > > > > > > > > >        pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > > > > >        return -ENOTSUP;
> > > > > > > > > > ..
> > > > > > > > > >
> > > > > > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > > > > > preferrential just to build libbpf statically and link against
> > > > > > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > > > > > 1.0.
> > > > > > > > > >
> > > > > > > > > > These patches change the libbpf test to only pass when at least
> > > > > > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > > > > > feature logic.
> > > > > > > > > >
> > > > > > > > > > The issue is discussed here:
> > > > > > > > > > https://lore.kernel.org/lkml/20230106151320.619514-1-irogers@google.com/
> > > > > > > > > > perf bpf:
> > > > > > > > > >
> > > > > > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > > > > > https://lore.kernel.org/lkml/Y71+eh00Ju7WeEFX@kernel.org/
> > > > > > > > > > This change goes further in removing logic that is now no longer
> > > > > > > > > > necessary.
> > > > > > > > > >
> > > > > > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > > > > > >
> > > > > > > > > I missed the:
> > > > > > > > > Acked/Tested-by: Jiri Olsa <jolsa@kernel.org>
> > > > > > > > > I believe we are waiting for package maintainer input.
> > > > > > > >
> > > > > > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > > > > > >
> > > > > > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > > > > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > > > > > for f38, so not sure how bad it'd be for f37
> > > > > > >
> > > > > > > jirka
> > > > > >
> > > > > > +Guilherme
> > > > > >
> > > > > > We were looking for maintainer input on these changes, but there is no
> > > > > > update in over a month. Here is the original lore link:
> > > > > > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > > > > > Should these changes land in perf-tools-next targeting Linux 6.4?
> > > > >
> > > > > Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> > > > > a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> > > > > stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
> > > > >
> > > >
> > > > libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
> > > > semantics is not enforced, unless libbpf_set_strict_mode() is enabled.
> > > >
> > > > So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
> > > > APIs that are in 1.0 (except newer one added later, but I'm not sure
> > > > perf needs any of the newer additions), and just stick to setting
> > > > libbpf_set_strict_mode() unconditionally.
> > >
> > > Thanks Andrii,
> > >
> >
> > Full disclosure, I'm totally supporting the switch to v1.0+, just
> > trying to be helpful here from the standpoint of 0.x vs 1.x libbpf
> > transition. See below. I believe you can keep 0.8+ dependency and drop
> > all the legacy code completely.
> >
> > But just take it as an information, and feel free to do whatever you
> > think is best with it.
> >
> > > The default perf build is to build against tools/lib/bpf and
> > > statically link libbpf in. This means by default we have the latest
> > > libbpf 1.2. If any perf code has a dependency on 0.8 (we don't support
> > > earlier) we need to #ifdef for it. Currently we have 7 feature tests
> > > for libbpf, but perhaps there is some cruft that's carried forward.
> > > The features are:
> > >  - btf__load_from_kernel_by_id
> >
> > v0.5 API
> >
> > >  - bpf_prog_load
> > >  - bpf_object__next_program
> > >  - bpf_object__next_map
> >
> > all three are v0.6 APIs
> >
> > >  - bpf_program__set_insns
> >
> > v0.8 API
> >
> > >  - btf__raw_data
> > >  - bpf_map_create
> >
> > both v0.6 API
> >
> > >
> > > The not present implementations look like:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/bpf-loader.c?h=perf-tools#n36
> > > ```
> > > int bpf_program__set_insns(struct bpf_program *prog __maybe_unused,
> > >   struct bpf_insn *new_insns __maybe_unused, size_t new_insn_cnt __maybe_unused)
> > > {
> > > pr_err("%s: not support, update libbpf\n", __func__);
> > > return -ENOTSUP;
> > > }
> > >
> > > int libbpf_register_prog_handler(const char *sec __maybe_unused,
> > >                                  enum bpf_prog_type prog_type __maybe_unused,
> > >                                  enum bpf_attach_type exp_attach_type
> > > __maybe_unused,
> > >                                  const struct libbpf_prog_handler_opts
> > > *opts __maybe_unused)
> > > {
> > > pr_err("%s: not support, update libbpf\n", __func__);
> > > return -ENOTSUP;
> > > }
> > > ```
> >
> > both are v0.8 APIs
> >
> > > This will basically mean that while you dynamically linked with libbpf
> > > 0.8 you are in all likelihood not going to get proper BPF support.
> > > These changes up the version requirement to 1.0 and get rid entirely
> > > of the feature tests - so no runtime failing implementations. If the
> >
> > 100% supportive on upgrade and dropping feature checks. My point is
> > that you don't need those feature checks with v0.8+ requirement.
> >
> > The only difference between staying on v0.8+ vs going all the way to
> > v1.0+ would be that you have to keep libbpf_set_strict() call. In
> > v1.0+ it's a noop, so could be dropped.
> >
> > > build determines at build time libbpf 1.0+ isn't present then it still
> > > executes, switching from dynamic libbpf to the default static libbpf
> > > that is at 1.2. As mentioned in this thread, distributions like Debian
> > > use the default static linking of libbpf.
> > >
> >
> > oh, that's nice, good to know
> >
> > > I'm not keen to hold on to the feature tests for the complexity that
> > > they hold and their needlessly (as you can always statically link)
> > > broken at runtime behavior. We could but my opinion is, let's not :-)
> >
> > I've been consistently advocating for static linking with libbpf, so
> > 100% support this.
> 
> Right, so I think we should move forward with these patches. We also

+1

jirka

> have had non-API changes to support libbpf 1.0+ like:
> https://lore.kernel.org/lkml/20221103045437.163510-4-irogers@google.com/
> and I'm worried about the state of these with libbpf 0.8.
> 
> Thanks,
> Ian
> 
> > >
> > > Thanks,
> > > Ian
> > >
> > > > > Best regards,
> > > > > -Guilherme
> > > > >

[v2,0/3] Assume libbpf 1.0+

Message

Comments