From: Menglong Dong <menglong.dong@linux.dev>
To: Menglong Dong <menglong8.dong@gmail.com>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: ast@kernel.org, andrii@kernel.org, davem@davemloft.net,
dsahern@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, netdev@vger.kernel.org,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 1/9] bpf: add tracing session support
Date: Fri, 19 Dec 2025 09:24:00 +0800 [thread overview]
Message-ID: <3387829.aeNJFYEL58@7940hx> (raw)
In-Reply-To: <CAEf4BzY3=qjfX385teDBs7G4Ae8LqFKwX0qMmDnSkkLi5qiWBg@mail.gmail.com>
On 2025/12/19 08:55 Andrii Nakryiko <andrii.nakryiko@gmail.com> write:
> On Wed, Dec 17, 2025 at 1:55 AM Menglong Dong <menglong8.dong@gmail.com> wrote:
> >
> > The tracing session is something that similar to kprobe session. It allow
> > to attach a single BPF program to both the entry and the exit of the
> > target functions.
> >
> > Introduce the struct bpf_fsession_link, which allows to add the link to
> > both the fentry and fexit progs_hlist of the trampoline.
> >
> > Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> > Co-developed-by: Leon Hwang <leon.hwang@linux.dev>
> > Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
> > ---
> > v4:
> > - instead of adding a new hlist to progs_hlist in trampoline, add the bpf
> > program to both the fentry hlist and the fexit hlist.
> > ---
> > include/linux/bpf.h | 20 +++++++++++
> > include/uapi/linux/bpf.h | 1 +
> > kernel/bpf/btf.c | 2 ++
> > kernel/bpf/syscall.c | 18 +++++++++-
> > kernel/bpf/trampoline.c | 36 +++++++++++++++----
> > kernel/bpf/verifier.c | 12 +++++--
> > net/bpf/test_run.c | 1 +
> > net/core/bpf_sk_storage.c | 1 +
> > tools/include/uapi/linux/bpf.h | 1 +
> > .../bpf/prog_tests/tracing_failure.c | 2 +-
> > 10 files changed, 83 insertions(+), 11 deletions(-)
> >
>
> [...]
>
> > int bpf_prog_ctx_arg_info_init(struct bpf_prog *prog,
> > const struct bpf_ctx_arg_aux *info, u32 cnt);
> >
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index 84ced3ed2d21..696a7d37db0e 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -1145,6 +1145,7 @@ enum bpf_attach_type {
> > BPF_NETKIT_PEER,
> > BPF_TRACE_KPROBE_SESSION,
> > BPF_TRACE_UPROBE_SESSION,
> > + BPF_TRACE_SESSION,
>
> FSESSION for consistency with FENTRY and FEXIT
OK
>
> > __MAX_BPF_ATTACH_TYPE
> > };
> >
>
> [...]
>
> > {
> > - enum bpf_tramp_prog_type kind;
> > - struct bpf_tramp_link *link_exiting;
> > + enum bpf_tramp_prog_type kind, okind;
> > + struct bpf_tramp_link *link_existing;
> > + struct bpf_fsession_link *fslink;
> > int err = 0;
> > int cnt = 0, i;
> >
> > - kind = bpf_attach_type_to_tramp(link->link.prog);
> > + okind = kind = bpf_attach_type_to_tramp(link->link.prog);
> > if (tr->extension_prog)
> > /* cannot attach fentry/fexit if extension prog is attached.
> > * cannot overwrite extension prog either.
> > @@ -621,13 +624,18 @@ static int __bpf_trampoline_link_prog(struct bpf_tramp_link *link,
> > BPF_MOD_JUMP, NULL,
> > link->link.prog->bpf_func);
> > }
> > + if (kind == BPF_TRAMP_SESSION) {
> > + /* deal with fsession as fentry by default */
> > + kind = BPF_TRAMP_FENTRY;
> > + cnt++;
> > + }
>
> this "pretend we are BPF_TRAMP_FENTRY" looks a bit hacky and is very
> hard to follow. I think it would be cleaner to have explicit small
> special cases for BPF_TRAMP_SESSION, and then generalize
> hlist_for_each_entry case by using a local variable for storing
> &tr->progs_hlist[kind] (which for TRAMP_SESSION you'll set to
> &tr->progs_hlist[BPF_TRAMP_FENTRY]). You'll then just do extra
> hlist_add_head/hlist_del_init and count manipulation. IMO, it's better
> than keeping in head what kind and okind is...
Ah, the way now does seem a little hacky. I tried to make this series
looks less complex by modifying the code as less as possible.
I'll use a explicit way here as you advised.
>
>
> > if (cnt >= BPF_MAX_TRAMP_LINKS)
> > return -E2BIG;
> > if (!hlist_unhashed(&link->tramp_hlist))
> > /* prog already linked */
> > return -EBUSY;
> > - hlist_for_each_entry(link_exiting, &tr->progs_hlist[kind], tramp_hlist) {
> > - if (link_exiting->link.prog != link->link.prog)
> > + hlist_for_each_entry(link_existing, &tr->progs_hlist[kind], tramp_hlist) {
> > + if (link_existing->link.prog != link->link.prog)
> > continue;
> > /* prog already linked */
> > return -EBUSY;
>
> [...]
>
> > @@ -23298,6 +23299,7 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > if (prog_type == BPF_PROG_TYPE_TRACING &&
> > insn->imm == BPF_FUNC_get_func_ret) {
> > if (eatype == BPF_TRACE_FEXIT ||
> > + eatype == BPF_TRACE_SESSION ||
> > eatype == BPF_MODIFY_RETURN) {
> > /* Load nr_args from ctx - 8 */
> > insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
> > @@ -24242,7 +24244,8 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> > if (tgt_prog->type == BPF_PROG_TYPE_TRACING &&
> > prog_extension &&
> > (tgt_prog->expected_attach_type == BPF_TRACE_FENTRY ||
> > - tgt_prog->expected_attach_type == BPF_TRACE_FEXIT)) {
> > + tgt_prog->expected_attach_type == BPF_TRACE_FEXIT ||
> > + tgt_prog->expected_attach_type == BPF_TRACE_SESSION)) {
> > /* Program extensions can extend all program types
> > * except fentry/fexit. The reason is the following.
> > * The fentry/fexit programs are used for performance
> > @@ -24257,7 +24260,7 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> > * beyond reasonable stack size. Hence extending fentry
> > * is not allowed.
> > */
> > - bpf_log(log, "Cannot extend fentry/fexit\n");
> > + bpf_log(log, "Cannot extend fentry/fexit/session\n");
>
> fsession?
OK
Thanks!
Menglong Dong
>
> > return -EINVAL;
> > }
> > } else {
> > @@ -24341,6 +24344,7 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> > case BPF_LSM_CGROUP:
> > case BPF_TRACE_FENTRY:
> > case BPF_TRACE_FEXIT:
> > + case BPF_TRACE_SESSION:
> > if (!btf_type_is_func(t)) {
> > bpf_log(log, "attach_btf_id %u is not a function\n",
> > btf_id);
>
> [...]
>
next prev parent reply other threads:[~2025-12-19 1:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-17 9:54 [PATCH bpf-next v4 0/9] bpf: tracing session supporting Menglong Dong
2025-12-17 9:54 ` [PATCH bpf-next v4 1/9] bpf: add tracing session support Menglong Dong
2025-12-19 0:55 ` Andrii Nakryiko
2025-12-19 1:24 ` Menglong Dong [this message]
2025-12-17 9:54 ` [PATCH bpf-next v4 2/9] bpf: use last 8-bits for the nr_args in trampoline Menglong Dong
2025-12-17 9:54 ` [PATCH bpf-next v4 3/9] bpf: add the kfunc bpf_fsession_is_return Menglong Dong
2025-12-17 9:54 ` [PATCH bpf-next v4 4/9] bpf: add the kfunc bpf_fsession_cookie Menglong Dong
2025-12-19 0:55 ` Andrii Nakryiko
2025-12-19 1:31 ` Menglong Dong
2025-12-19 12:01 ` Menglong Dong
2025-12-17 9:54 ` [PATCH bpf-next v4 5/9] bpf,x86: introduce emit_st_r0_imm64() for trampoline Menglong Dong
2025-12-17 9:54 ` [PATCH bpf-next v4 6/9] bpf,x86: add tracing session supporting for x86_64 Menglong Dong
2025-12-19 0:55 ` Andrii Nakryiko
2025-12-19 1:41 ` Menglong Dong
2025-12-19 16:56 ` Andrii Nakryiko
2025-12-17 9:54 ` [PATCH bpf-next v4 7/9] libbpf: add support for tracing session Menglong Dong
2025-12-19 0:55 ` Andrii Nakryiko
2025-12-19 1:42 ` Menglong Dong
2025-12-17 9:54 ` [PATCH bpf-next v4 8/9] selftests/bpf: add testcases " Menglong Dong
2025-12-17 10:24 ` bot+bpf-ci
2025-12-17 11:42 ` Menglong Dong
2025-12-17 9:54 ` [PATCH bpf-next v4 9/9] selftests/bpf: test fsession mixed with fentry and fexit Menglong Dong
2025-12-17 10:24 ` bot+bpf-ci
2025-12-17 10:37 ` Menglong Dong
2025-12-19 0:55 ` [PATCH bpf-next v4 0/9] bpf: tracing session supporting Andrii Nakryiko
2025-12-19 1:18 ` Menglong Dong
2025-12-19 16:55 ` Andrii Nakryiko
2025-12-20 1:12 ` Menglong Dong
2025-12-20 9:01 ` Menglong Dong
2025-12-20 12:22 ` Menglong Dong
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=3387829.aeNJFYEL58@7940hx \
--to=menglong.dong@linux.dev \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=hpa@zytor.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=menglong8.dong@gmail.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).