summaryrefslogtreecommitdiffstats
path: root/include/linux
diff options
context:
space:
mode:
authorAlexei Starovoitov <ast@kernel.org>2024-01-04 20:31:34 -0800
committerAlexei Starovoitov <ast@kernel.org>2024-01-04 20:40:54 -0800
commit5fe4ee6ae187523f710f1b93024437a073d88b17 (patch)
tree0597b83407e92f101be92851c0b2e0eb5181b045 /include/linux
parent00bc8988807985e32f5103f1ac099baf593bd8a3 (diff)
parente02feb3f1f47509ec1e07b604bfbeff8c3b4e639 (diff)
downloadlinux-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.h1
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;