[PATCH bpf-next] perf: mute libbpf API deprecations temporarily

[PATCH bpf-next] perf: mute libbpf API deprecations temporarily

[Andrii Nakryiko]

Libbpf development version was bumped to 0.7 in c93faaaf2f67
("libbpf: Deprecate bpf_prog_load_xattr() API"), activating a bunch of
previously scheduled deprecations. Most APIs are pretty straightforward
to replace with newer APIs, but perf has a complicated mixed setup with
libbpf used both as static and shared configurations, which makes it
non-trivial to migrate the APIs.

Further, bpf_program__set_prep() needs more involved refactoring, which
will require help from Arnaldo and/or Jiri.

So for now, mute deprecation warnings and work on migrating perf off of
deprecated APIs separately with the input from owners of the perf tool.

Fixes: c93faaaf2f67 ("libbpf: Deprecate bpf_prog_load_xattr() API")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
 tools/perf/tests/bpf.c       | 4 ++++
 tools/perf/util/bpf-loader.c | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
index 2bf146e49ce8..c52bf10f746e 100644
--- a/tools/perf/tests/bpf.c
+++ b/tools/perf/tests/bpf.c
@@ -312,9 +312,13 @@ static int check_env(void)
 		return err;
 	}
 
+/* temporarily disable libbpf deprecation warnings */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
 	err = bpf_load_program(BPF_PROG_TYPE_KPROBE, insns,
 			       sizeof(insns) / sizeof(insns[0]),
 			       license, kver_int, NULL, 0);
+#pragma GCC diagnostic pop
 	if (err < 0) {
 		pr_err("Missing basic BPF support, skip this test: %s\n",
 		       strerror(errno));
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index fbb3c4057c30..528aeb0ab79d 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -29,6 +29,9 @@
 
 #include <internal/xyarray.h>
 
+/* temporarily disable libbpf deprecation warnings */
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+
 static int libbpf_perf_print(enum libbpf_print_level level __attribute__((unused)),
 			      const char *fmt, va_list args)
 {
-- 
2.30.2

Re: [PATCH bpf-next] perf: mute libbpf API deprecations temporarily

[Andrii Nakryiko]

On Thu, Dec 2, 2021 at 4:46 PM Andrii Nakryiko <andrii@kernel.org> wrote:
>
> Libbpf development version was bumped to 0.7 in c93faaaf2f67
> ("libbpf: Deprecate bpf_prog_load_xattr() API"), activating a bunch of
> previously scheduled deprecations. Most APIs are pretty straightforward
> to replace with newer APIs, but perf has a complicated mixed setup with
> libbpf used both as static and shared configurations, which makes it
> non-trivial to migrate the APIs.
>
> Further, bpf_program__set_prep() needs more involved refactoring, which
> will require help from Arnaldo and/or Jiri.
>
> So for now, mute deprecation warnings and work on migrating perf off of
> deprecated APIs separately with the input from owners of the perf tool.
>
> Fixes: c93faaaf2f67 ("libbpf: Deprecate bpf_prog_load_xattr() API")
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---

Stephen,

This patch (when applied to bpf-next) should fix the build failure you
reported in your recent "linux-next: build failure after merge of the
bpf-next tree" email (that I didn't get directly, but thankfully
Alexei forwarded to me). Can you please also cc bpf@vger.kernel.orgfor
future bpf-next tree issues, as that's a more directly related mailing
list (ideally also cc me at andrii@kernel.org directly so that we
don't rely on Gmail not dropping the email, I've, unfortunately, had
multiple problems with this recently). Thanks for understanding!

Arnaldo, Jiri,

Getting rid of most deprecations is pretty trivial, if not for the
hybrid static/dynamic setup. Please advise on the path forward. Do I
do __weak re-definitions of new APIs and switch the source code to new
variants?

As for bpf_program__set_prep(), assuming it's used to do program
cloning, bpf_program__insns() is a more straightforward and cleaner
way to do it now. But the logic seems to be more involved, so I'd like
you guys to do this conversion, if that's not too much trouble.

Regardless, let's work together to clean up perf's use of deprecated
APIs. Thanks!

>  tools/perf/tests/bpf.c       | 4 ++++
>  tools/perf/util/bpf-loader.c | 3 +++
>  2 files changed, 7 insertions(+)
>
> diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
> index 2bf146e49ce8..c52bf10f746e 100644
> --- a/tools/perf/tests/bpf.c
> +++ b/tools/perf/tests/bpf.c
> @@ -312,9 +312,13 @@ static int check_env(void)
>                 return err;
>         }
>
> +/* temporarily disable libbpf deprecation warnings */
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
>         err = bpf_load_program(BPF_PROG_TYPE_KPROBE, insns,
>                                sizeof(insns) / sizeof(insns[0]),
>                                license, kver_int, NULL, 0);
> +#pragma GCC diagnostic pop
>         if (err < 0) {
>                 pr_err("Missing basic BPF support, skip this test: %s\n",
>                        strerror(errno));
> diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
> index fbb3c4057c30..528aeb0ab79d 100644
> --- a/tools/perf/util/bpf-loader.c
> +++ b/tools/perf/util/bpf-loader.c
> @@ -29,6 +29,9 @@
>
>  #include <internal/xyarray.h>
>
> +/* temporarily disable libbpf deprecation warnings */
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> +
>  static int libbpf_perf_print(enum libbpf_print_level level __attribute__((unused)),
>                               const char *fmt, va_list args)
>  {
> --
> 2.30.2
>

Re: [PATCH bpf-next] perf: mute libbpf API deprecations temporarily

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

Hi Andrii,

On Thu, 2 Dec 2021 17:00:40 -0800 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> This patch (when applied to bpf-next) should fix the build failure you
> reported in your recent "linux-next: build failure after merge of the
> bpf-next tree" email (that I didn't get directly, but thankfully
> Alexei forwarded to me). Can you please also cc bpf@vger.kernel.orgfor
> future bpf-next tree issues, as that's a more directly related mailing
> list (ideally also cc me at andrii@kernel.org directly so that we
> don't rely on Gmail not dropping the email, I've, unfortunately, had
> multiple problems with this recently). Thanks for understanding!

Hopefully that patch will be applied soon :-)

I have added the bpf list and you to my contacts for the bpf and
bpf-next trees in linux-next.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]