summaryrefslogtreecommitdiffstats
path: root/tools/lib/bpf/libbpf_version.h
diff options
context:
space:
mode:
authorAndrii Nakryiko <andrii@kernel.org>2022-03-04 17:01:27 -0800
committerAlexei Starovoitov <ast@kernel.org>2022-03-05 09:38:15 -0800
commit4fa5bcfe07f7e97d9a140c465e1056c91651c41d (patch)
tree9de693bba52afa61d531f3d9b13cf70a368c730b /tools/lib/bpf/libbpf_version.h
parentd59e3cbaef707f0d3dc1e3b6735cb25060ca74c2 (diff)
downloadlinux-4fa5bcfe07f7e97d9a140c465e1056c91651c41d.tar.gz
linux-4fa5bcfe07f7e97d9a140c465e1056c91651c41d.tar.bz2
linux-4fa5bcfe07f7e97d9a140c465e1056c91651c41d.zip
libbpf: Allow BPF program auto-attach handlers to bail out
Allow some BPF program types to support auto-attach only in subste of cases. Currently, if some BPF program type specifies attach callback, it is assumed that during skeleton attach operation all such programs either successfully attach or entire skeleton attachment fails. If some program doesn't support auto-attachment from skeleton, such BPF program types shouldn't have attach callback specified. This is limiting for cases when, depending on how full the SEC("") definition is, there could either be enough details to support auto-attach or there might not be and user has to use some specific API to provide more details at runtime. One specific example of such desired behavior might be SEC("uprobe"). If it's specified as just uprobe auto-attach isn't possible. But if it's SEC("uprobe/<some_binary>:<some_func>") then there are enough details to support auto-attach. Note that there is a somewhat subtle difference between auto-attach behavior of BPF skeleton and using "generic" bpf_program__attach(prog) (which uses the same attach handlers under the cover). Skeleton allow some programs within bpf_object to not have auto-attach implemented and doesn't treat that as an error. Instead such BPF programs are just skipped during skeleton's (optional) attach step. bpf_program__attach(), on the other hand, is called when user *expects* auto-attach to work, so if specified program doesn't implement or doesn't support auto-attach functionality, that will be treated as an error. Another improvement to the way libbpf is handling SEC()s would be to not require providing dummy kernel function name for kprobe. Currently, SEC("kprobe/whatever") is necessary even if actual kernel function is determined by user at runtime and bpf_program__attach_kprobe() is used to specify it. With changes in this patch, it's possible to support both SEC("kprobe") and SEC("kprobe/<actual_kernel_function"), while only in the latter case auto-attach will be performed. In the former one, such kprobe will be skipped during skeleton attach operation. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Tested-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Link: https://lore.kernel.org/bpf/20220305010129.1549719-2-andrii@kernel.org
Diffstat (limited to 'tools/lib/bpf/libbpf_version.h')
0 files changed, 0 insertions, 0 deletions