diff options
author | Alexei Starovoitov <ast@kernel.org> | 2024-01-04 20:31:34 -0800 |
---|---|---|
committer | Alexei Starovoitov <ast@kernel.org> | 2024-01-04 20:40:54 -0800 |
commit | 5fe4ee6ae187523f710f1b93024437a073d88b17 (patch) | |
tree | 0597b83407e92f101be92851c0b2e0eb5181b045 /include/linux | |
parent | 00bc8988807985e32f5103f1ac099baf593bd8a3 (diff) | |
parent | e02feb3f1f47509ec1e07b604bfbeff8c3b4e639 (diff) | |
download | linux-stable-5fe4ee6ae187523f710f1b93024437a073d88b17.tar.gz linux-stable-5fe4ee6ae187523f710f1b93024437a073d88b17.tar.bz2 linux-stable-5fe4ee6ae187523f710f1b93024437a073d88b17.zip |
Merge branch 'relax-tracing-prog-recursive-attach-rules'
Dmitrii Dolgov says:
====================
Relax tracing prog recursive attach rules
Currently, it's not allowed to attach an fentry/fexit prog to another
fentry/fexit. At the same time it's not uncommon to see a tracing
program with lots of logic in use, and the attachment limitation
prevents usage of fentry/fexit for performance analysis (e.g. with
"bpftool prog profile" command) in this case. An example could be
falcosecurity libs project that uses tp_btf tracing programs for
offloading certain part of logic into tail-called programs, but the
use-case is still generic enough -- a tracing program could be
complicated and heavy enough to warrant its profiling, yet frustratingly
it's not possible to do so use best tooling for that.
Following the corresponding discussion [1], the reason for that is to
avoid tracing progs call cycles without introducing more complex
solutions. But currently it seems impossible to load and attach tracing
programs in a way that will form such a cycle. Replace "no same type"
requirement with verification that no more than one level of attachment
nesting is allowed. In this way only one fentry/fexit program could be
attached to another fentry/fexit to cover profiling use case, and still
no cycle could be formed.
The series contains a test for recursive attachment, as well as a fix +
test for an issue in re-attachment branch of bpf_tracing_prog_attach.
When preparing the test for the main change set, I've stumbled upon the
possibility to construct a sequence of events when attach_btf would be
NULL while computing a trampoline key. It doesn't look like this issue
is triggered by the main change, because the reproduces doesn't actually
need to have an fentry attachment chain.
[1]: https://lore.kernel.org/bpf/20191108064039.2041889-16-ast@kernel.org/
====================
Link: https://lore.kernel.org/r/20240103190559.14750-1-9erthalion6@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'include/linux')
-rw-r--r-- | include/linux/bpf.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/include/linux/bpf.h b/include/linux/bpf.h index 7671530d6e4e..e30100597d0a 100644 --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -1449,6 +1449,7 @@ struct bpf_prog_aux { bool dev_bound; /* Program is bound to the netdev. */ bool offload_requested; /* Program is bound and offloaded to the netdev. */ bool attach_btf_trace; /* true if attaching to BTF-enabled raw tp */ + bool attach_tracing_prog; /* true if tracing another tracing program */ bool func_proto_unreliable; bool sleepable; bool tail_call_reachable; |