BPF List
 help / color / mirror / Atom feed
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,
	Dmitrii Dolgov <9erthalion6@gmail.com>
Subject: [PATCH bpf-next v3 0/3] Relax tracing prog recursive attach rules
Date: Wed, 29 Nov 2023 20:16:37 +0100	[thread overview]
Message-ID: <20231129191643.6842-1-9erthalion6@gmail.com> (raw)

Currently, it's not allowed to attach an fentry/fexit prog to another
one of the same type. 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. Relax "no same type" requirement to "no progs that are
already an attach target themselves" for the tracing type. In this way
only a standalone tracing program (without any other progs attached to
it) could be attached to another one, and no cycle could be formed.

Note that currently, due to various limitations, it's actually not
possible to form such an attachment cycle the original implementation
was prohibiting. It seems that the idea was to make this part robust
even in the view of potential future changes.

The series contains a test for recursive attachment, as well as a fix +
test for what looks like 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
  bpf, selftest/bpf: Fix re-attachment branch in bpf_tracing_prog_attach

 include/linux/bpf.h                           |   2 +
 include/uapi/linux/bpf.h                      |   1 +
 kernel/bpf/syscall.c                          |  16 ++-
 kernel/bpf/verifier.c                         |  19 ++-
 tools/bpf/bpftool/prog.c                      |   3 +
 tools/include/uapi/linux/bpf.h                |   1 +
 .../bpf/prog_tests/recursive_attach.c         | 133 ++++++++++++++++++
 .../selftests/bpf/progs/fentry_recursive.c    |  19 +++
 .../bpf/progs/fentry_recursive_target.c       |  31 ++++
 9 files changed, 220 insertions(+), 5 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: 100888fb6d8a185866b1520031ee7e3182b173de
-- 
2.41.0


             reply	other threads:[~2023-11-29 19:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 19:16 Dmitrii Dolgov [this message]
2023-11-29 19:16 ` [PATCH bpf-next v3 1/3] bpf: Relax tracing prog recursive attach rules Dmitrii Dolgov
2023-11-29 19:16 ` [PATCH bpf-next v3 2/3] selftests/bpf: Add test for recursive attachment of tracing progs Dmitrii Dolgov
2023-11-29 19:16 ` [PATCH bpf-next v3 3/3] bpf, selftest/bpf: Fix re-attachment branch in 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=20231129191643.6842-1-9erthalion6@gmail.com \
    --to=9erthalion6@gmail.com \
    --cc=andrii@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox