[bpf-next,0/3] Introduce bpf_object__prepare

Message

Mykyta Yatsenko Feb. 28, 2025, 5:52 p.m. UTC

From: Mykyta Yatsenko <[e-mail]>

Introduce a new libbpf API function bpf_object__prepare enabling more
granular control over the process of bpf_object loading.
bpf_object__prepare runs the same steps that bpf_object__load is running,
before the actual loading of BPF programs.
This API could be useful when we need access to initialized fields of
bpf_object before program loading, for example: currently we can't pass
bpf_token into bpf_program__set_attach_target, because token initialization
is done during loading.

Mykyta Yatsenko (3):
  libbpf: introduce more granular state for bpf_object
  libbpf: split bpf object load into prepare/load
  selftests/bpf: add tests for bpf_object__prepare

 tools/lib/bpf/libbpf.c                        | 194 ++++++++++++------
 tools/lib/bpf/libbpf.h                        |   9 +
 tools/lib/bpf/libbpf.map                      |   1 +
 .../selftests/bpf/prog_tests/prepare.c        |  99 +++++++++
 tools/testing/selftests/bpf/progs/prepare.c   |  28 +++
 5 files changed, 267 insertions(+), 64 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/prepare.c
 create mode 100644 tools/testing/selftests/bpf/progs/prepare.c

Comments

Andrii Nakryiko Feb. 28, 2025, 10:39 p.m. UTC | #1

On Fri, Feb 28, 2025 at 9:53 AM Mykyta Yatsenko
<[e-mail]> wrote:
>
> From: Mykyta Yatsenko <[e-mail]>
>
> Introduce a new libbpf API function bpf_object__prepare enabling more
> granular control over the process of bpf_object loading.
> bpf_object__prepare runs the same steps that bpf_object__load is running,
> before the actual loading of BPF programs.
> This API could be useful when we need access to initialized fields of
> bpf_object before program loading, for example: currently we can't pass
> bpf_token into bpf_program__set_attach_target, because token initialization
> is done during loading.
>

I think this cover letter and commit messages in patch 1/2 could use a
bit more work. Here, I'd elaborate on anticipated use cases (and there
are a few already):

  1) taking advantage of BPF token for freplace programs that might
need to lookup BTF of other programs (I'd also mention that we don't
want to move BPF token creation to open step, as open step is "no
privilege assumption" step so that tools like bpftool can generate
skeleton, discover the structure of BPF object, etC).

  2) stopping at prepare gives users finalized BPF program
instructions (with subprogs appended, everything relocated and
finalized, etc). And that property can be taken advantage of by
veristat (and similar tools) that might want to process one program at
a time, but would like to avoid relatively slow ELF parsing and
processing; and even BPF selftests itself (RUN_TESTS part of it at
least) would benefit from this by eliminating waste of re-processing
ELF many times over.


I.e., think about writing this for someone that doesn't have enough
context. They should get at least some of it from your descriptions.

> Mykyta Yatsenko (3):
>   libbpf: introduce more granular state for bpf_object
>   libbpf: split bpf object load into prepare/load
>   selftests/bpf: add tests for bpf_object__prepare
>
>  tools/lib/bpf/libbpf.c                        | 194 ++++++++++++------
>  tools/lib/bpf/libbpf.h                        |   9 +
>  tools/lib/bpf/libbpf.map                      |   1 +
>  .../selftests/bpf/prog_tests/prepare.c        |  99 +++++++++
>  tools/testing/selftests/bpf/progs/prepare.c   |  28 +++
>  5 files changed, 267 insertions(+), 64 deletions(-)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/prepare.c
>  create mode 100644 tools/testing/selftests/bpf/progs/prepare.c
>
> --
> 2.48.1
>