Message-ID: <CAP-5=fWvMFXOaKA0bKaKdzYjqOxTCXGapJy-4x34hJyZxqD-Dw@mail.gmail.com>
Date:   Thu, 9 Mar 2023 19:26:35 -0800
From:   Ian Rogers <irogers@...gle.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Guilherme Amadio <amadio@...too.org>,
        Jiri Olsa <olsajiri@...il.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Andres Freund <andres@...razel.de>,
        Quentin Monnet <quentin@...valent.com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        Christy Lee <christylee@...com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        bpf@...r.kernel.org, Michael Petlan <mpetlan@...hat.com>,
        Ben Hutchings <ben@...adent.org.uk>
Subject: Re: [PATCH v2 0/3] Assume libbpf 1.0+

On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
>
> On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@...too.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@...il.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@...gle.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@...nel.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
> >

Powered by blists - more mailing lists