diff options
| author | Dmitrii Dolgov <[email protected]> | 2024-01-03 20:05:44 +0100 |
|---|---|---|
| committer | Alexei Starovoitov <[email protected]> | 2024-01-04 20:31:34 -0800 |
| commit | 19bfcdf9498aa968ea293417fbbc39e523527ca8 (patch) | |
| tree | b6f41738ec49d90299a77b1eab8fea793cf04dfd /tools/perf/scripts/python/failed-syscalls-by-pid.py | |
| parent | 00bc8988807985e32f5103f1ac099baf593bd8a3 (diff) | |
bpf: Relax tracing prog recursive attach rules
Currently, it's not allowed to attach an fentry/fexit prog to another
one 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.
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. The limitation is coming
from the fact that attach_prog_fd is specified at the prog load (thus
making it impossible to attach to a program loaded after it in this
way), as well as tracing progs not implementing link_detach.
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. To implement,
add a new field into bpf_prog_aux to track nested attachment for tracing
programs.
[1]: https://lore.kernel.org/bpf/[email protected]/
Acked-by: Jiri Olsa <[email protected]>
Acked-by: Song Liu <[email protected]>
Signed-off-by: Dmitrii Dolgov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/failed-syscalls-by-pid.py')
0 files changed, 0 insertions, 0 deletions