From: Dmitrii Dolgov <9erthalion6@gmail.com>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev,
dan.carpenter@linaro.org, olsajiri@gmail.com, asavkov@redhat.com,
Dmitrii Dolgov <9erthalion6@gmail.com>
Subject: [PATCH bpf-next v10 0/4] Relax tracing prog recursive attach rules
Date: Wed, 20 Dec 2023 19:04:15 +0100 [thread overview]
Message-ID: <20231220180422.8375-1-9erthalion6@gmail.com> (raw)
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/
Dmitrii Dolgov (3):
bpf: Relax tracing prog recursive attach rules
selftests/bpf: Add test for recursive attachment of tracing progs
selftests/bpf: Test re-attachment fix for bpf_tracing_prog_attach
Jiri Olsa (1):
bpf: Fix re-attachment branch in bpf_tracing_prog_attach
include/linux/bpf.h | 1 +
kernel/bpf/syscall.c | 32 ++-
kernel/bpf/verifier.c | 39 +--
.../bpf/prog_tests/recursive_attach.c | 237 ++++++++++++++++++
.../selftests/bpf/progs/fentry_recursive.c | 16 ++
.../bpf/progs/fentry_recursive_target.c | 27 ++
6 files changed, 337 insertions(+), 15 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/recursive_attach.c
create mode 100644 tools/testing/selftests/bpf/progs/fentry_recursive.c
create mode 100644 tools/testing/selftests/bpf/progs/fentry_recursive_target.c
base-commit: 40d0eb0259ae77ace3e81d7454d1068c38bc95c2
--
2.41.0
next reply other threads:[~2023-12-20 18:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 18:04 Dmitrii Dolgov [this message]
2023-12-20 18:04 ` [PATCH bpf-next v10 1/4] bpf: Relax tracing prog recursive attach rules Dmitrii Dolgov
2023-12-21 18:02 ` Jiri Olsa
2023-12-21 20:24 ` Dmitry Dolgov
2023-12-21 22:13 ` Jiri Olsa
2023-12-22 14:05 ` Dmitry Dolgov
2023-12-20 18:04 ` [PATCH bpf-next v10 2/4] selftests/bpf: Add test for recursive attachment of tracing progs Dmitrii Dolgov
2023-12-21 18:02 ` Jiri Olsa
2023-12-20 18:04 ` [PATCH bpf-next v10 3/4] bpf: Fix re-attachment branch in bpf_tracing_prog_attach Dmitrii Dolgov
2023-12-20 18:04 ` [PATCH bpf-next v10 4/4] selftests/bpf: Test re-attachment fix for bpf_tracing_prog_attach Dmitrii Dolgov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231220180422.8375-1-9erthalion6@gmail.com \
--to=9erthalion6@gmail.com \
--cc=andrii@kernel.org \
--cc=asavkov@redhat.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=daniel@iogearbox.net \
--cc=martin.lau@linux.dev \
--cc=olsajiri@gmail.com \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.