Merge branch 'libbpf: add bpf_program__insns() accessor'
authorAlexei Starovoitov <ast@kernel.org>
Tue, 26 Oct 2021 01:37:21 +0000 (18:37 -0700)
committerAlexei Starovoitov <ast@kernel.org>
Tue, 26 Oct 2021 01:37:22 +0000 (18:37 -0700)
commit124c6003bf12351a6feef231849d570cd03c760c
tree20e332370af87375b7a5675cd45e7a0705decfb6
parent9327acd0f9a49394e6567ac79dd55635527e1f56
parentc4813e969ac471af730902377a2656b6b1b92c4d
Merge branch 'libbpf: add bpf_program__insns() accessor'

Andrii Nakryiko says:

====================

Add libbpf APIs to access BPF program instructions. Both before and after
libbpf processing (before and after bpf_object__load()). This allows to
inspect what's going on with BPF program assembly instructions as libbpf
performs its processing magic.

But in more practical terms, this allows to do a no-brainer BPF program
cloning, which is something you need when working with fentry/fexit BPF
programs to be able to attach the same BPF program code to multiple kernel
functions. Currently, kernel needs multiple copies of BPF programs, each
loaded with its own target BTF ID. retsnoop is one such example that
previously had to rely on bpf_program__set_prep() API to hijack program
instructions ([0] for before and after).

Speaking of bpf_program__set_prep() API and the whole concept of
multiple-instance BPF programs in libbpf, all that is scheduled for
deprecation in v0.7. It doesn't work well, it's cumbersome, and it will become
more broken as libbpf adds more functionality. So deprecate and remove it in
libbpf 1.0. It doesn't seem to be used by anyone anyways (except for that
retsnoop hack, which is now much cleaner with new APIs as can be seen in [0]).

  [0] https://github.com/anakryiko/retsnoop/pull/1
====================

Signed-off-by: Alexei Starovoitov <ast@kernel.org>