]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commitf47254c3fafa43d4cc66755ef3775398cc9ae48d
tree20e332370af87375b7a5675cd45e7a0705decfb6
parent39a45f692467e34ff6f90a46841c2968c6a9c1f0
parent72c0063455256f9655e4496fee859741de51ff0f
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>