]> 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)
commit7124be5ab6c06ca05030c8685162788130f3b6d7
tree20e332370af87375b7a5675cd45e7a0705decfb6
parent855b4c47677c31a053f270b8525175a1443d288d
parent4c532492a57e368fcdf873f16c030418bb7d8178
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>