bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Marchevsky <davemarchevsky@fb.com>
To: <bpf@vger.kernel.org>, <linux-perf-users@vger.kernel.org>
Cc: Song Liu <songliubraving@fb.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Marchevsky <davemarchevsky@fb.com>
Subject: [PATCH v3 bpf-next 0/4] libbpf: deprecate bpf_program__get_prog_info_linear
Date: Mon, 1 Nov 2021 15:43:53 -0700	[thread overview]
Message-ID: <20211101224357.2651181-1-davemarchevsky@fb.com> (raw)

bpf_program__get_prog_info_linear is a helper which wraps the
bpf_obj_get_info_by_fd BPF syscall with some niceties that put
all dynamic-length bpf_prog_info in one buffer contiguous with struct
bpf_prog_info, and simplify the selection of which dynamic data to grab.

The resultant combined struct, bpf_prog_info_linear, is persisted to
file by 'perf' to enable later annotation of BPF prog data. libbpf
includes some vaddr <-> offset conversion helpers for
struct bpf_prog_info_linear to simplify this.

This functionality is heavily tailored to perf's usecase, so its use as
a general prog info API should be deemphasized in favor of just calling
bpf_obj_get_info_by_fd, which can be more easily fit to purpose. Some
examples from caller migrations in this series:

  * Some callers weren't requesting or using dynamic-sized prog info and
    are well served by a simple get_info_by_fd call (e.g.
    dump_prog_id_as_func_ptr in bpftool)
  * Some callers were requesting all of a specific dynamic info type but
    only using the first record, so can avoid unnecessary malloc by
    only requesting 1 (e.g. profile_target_name in bpftool)
  * bpftool's do_dump saves some malloc/free by growing and reusing its
    dynamic prog_info buf as it loops over progs to grab info and dump.

Perf does need the full functionality of
bpf_program__get_prog_info_linear and its accompanying structs +
helpers, so copy the code to its codebase, migrate all other uses in the
tree, and deprecate the helper in libbpf.

Since the deprecated symbols continue to be included in perf some
renaming was necessary in perf's copy, otherwise functionality is
unchanged.

This work was previously discussed in libbpf's issue tracker [0].

[0]: https://github.com/libbpf/libbpf/issues/313

v2->v3:
  * Remove v2's patch 1 ("libbpf: Migrate internal use of
    bpf_program__get_prog_info_linear"), which was applied [Andrii]
  * Add new patch 1 migrating error checking of libbpf calls to
    new scheme [Andrii, Quentin]
  * In patch 2, fix != -1 error check of libbpf call, improper realloc
    handling, and get rid of confusing macros [Andrii]
  * In patch 4, deprecate starting from 0.6 instead of 0.7 [Andrii]

v1->v2: fix bpftool do_dump changes to clear bpf_prog_info after use and
correctly pass realloc'd ptr back (patch 2)

Dave Marchevsky (4):
  bpftool: Migrate -1 err checks of libbpf fn calls
  bpftool: use bpf_obj_get_info_by_fd directly
  perf: pull in bpf_program__get_prog_info_linear
  libbpf: deprecate bpf_program__get_prog_info_linear

 tools/bpf/bpftool/btf_dumper.c                |  42 +--
 tools/bpf/bpftool/prog.c                      | 158 ++++++++---
 tools/bpf/bpftool/struct_ops.c                |   2 +-
 tools/lib/bpf/libbpf.h                        |   3 +
 .../Documentation/perf.data-file-format.txt   |   2 +-
 tools/perf/util/Build                         |   1 +
 tools/perf/util/annotate.c                    |   3 +-
 tools/perf/util/bpf-event.c                   |  41 ++-
 tools/perf/util/bpf-event.h                   |   2 +-
 tools/perf/util/bpf-utils.c                   | 261 ++++++++++++++++++
 tools/perf/util/bpf-utils.h                   |  76 +++++
 tools/perf/util/bpf_counter.c                 |   6 +-
 tools/perf/util/dso.c                         |   1 +
 tools/perf/util/env.c                         |   1 +
 tools/perf/util/header.c                      |  13 +-
 15 files changed, 527 insertions(+), 85 deletions(-)
 create mode 100644 tools/perf/util/bpf-utils.c
 create mode 100644 tools/perf/util/bpf-utils.h

-- 
2.30.2


             reply	other threads:[~2021-11-01 22:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-01 22:43 Dave Marchevsky [this message]
2021-11-01 22:43 ` [PATCH v3 bpf-next 1/4] bpftool: Migrate -1 err checks of libbpf fn calls Dave Marchevsky
2021-11-01 22:43 ` [PATCH v3 bpf-next 2/4] bpftool: use bpf_obj_get_info_by_fd directly Dave Marchevsky
2021-11-01 22:43 ` [PATCH v3 bpf-next 3/4] perf: pull in bpf_program__get_prog_info_linear Dave Marchevsky
2021-11-01 22:43 ` [PATCH v3 bpf-next 4/4] libbpf: deprecate bpf_program__get_prog_info_linear Dave Marchevsky
2021-11-02 23:06 ` [PATCH v3 bpf-next 0/4] " Andrii Nakryiko
2021-11-03 11:26   ` Quentin Monnet
2021-11-03 18:21     ` Andrii Nakryiko
2021-11-03 18:50       ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211101224357.2651181-1-davemarchevsky@fb.com \
    --to=davemarchevsky@fb.com \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=songliubraving@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).