From: Jiri Olsa <olsajiri@gmail.com>
To: Leon Hwang <leon.hwang@linux.dev>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Emil Tsalapatis <emil@etsalapatis.com>,
Ihor Solodrai <ihor.solodrai@linux.dev>,
Quentin Monnet <qmo@kernel.org>, Shuah Khan <shuah@kernel.org>,
Mykyta Yatsenko <yatsenko@meta.com>,
Avinash Duduskar <avinash.duduskar@gmail.com>,
Anton Protopopov <a.s.protopopov@gmail.com>,
Amery Hung <ameryhung@gmail.com>, Jordan Rife <jordan@jrife.io>,
Rong Tao <rongtao@cestc.cn>, Eyal Birger <eyal.birger@gmail.com>,
Pu Lehui <pulehui@huawei.com>,
Jingguo Tan <tanjingguo@huawei.com>, Lin Ma <malin89@huawei.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf-next 04/13] bpf: Add tracing_multi link support for bpf progs
Date: Mon, 10 Aug 2026 15:13:41 +0200 [thread overview]
Message-ID: <annOhedRtHBce3px@krava> (raw)
In-Reply-To: <20260809150111.45000-5-leon.hwang@linux.dev>
On Sun, Aug 09, 2026 at 11:01:02PM +0800, Leon Hwang wrote:
SNIP
> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> index eddd259d3776..fc51ea2428be 100644
> --- a/kernel/bpf/trampoline.c
> +++ b/kernel/bpf/trampoline.c
> @@ -1572,12 +1572,23 @@ static int update_fentry_multi(struct bpf_trampoline *tr, u32 orig_flags,
> struct bpf_tramp_image *im, struct ftrace_hash *hash,
> struct bpf_tracing_multi_data *data)
> {
> - unsigned long addr = (unsigned long)(im ? im->image : tr->cur_image->image);
> + if (tr->func.ftrace_managed) {
> + unsigned long addr = (unsigned long)(im ? im->image : tr->cur_image->image);
>
> - if (bpf_trampoline_use_jmp(tr->flags))
> - addr = ftrace_jmp_set(addr);
> + if (bpf_trampoline_use_jmp(tr->flags))
> + addr = ftrace_jmp_set(addr);
> +
> + ftrace_hash_add(hash, data->entry, tr->ip, addr);
> + } else {
> + void *old_addr = tr->cur_image ? tr->cur_image->image : NULL;
> + void *new_addr = im ? im->image : NULL;
> + int ret;
> +
> + ret = bpf_trampoline_update_fentry(tr, orig_flags, old_addr, new_addr);
> + if (ret)
> + return ret;
> + }
hum, so IIUC this sequentially attaches to target bpf program as it
would with current API, so there's no attachent speedup, right?
>
> - ftrace_hash_add(hash, data->entry, tr->ip, addr);
> tr->cur_image = im;
> return 0;
> }
> @@ -1627,6 +1638,18 @@ static void bpf_trampoline_multi_attach_free(struct bpf_trampoline *tr)
>
> static void bpf_trampoline_multi_attach_rollback(struct bpf_trampoline *tr)
> {
> + if (!tr->func.ftrace_managed) {
> + void *failed_addr = tr->cur_image ? tr->cur_image->image : NULL;
> + void *old_addr = tr->multi_attach.old_image ?
> + tr->multi_attach.old_image->image : NULL;
> + u32 orig_flags = tr->flags;
> + int ret;
> +
> + tr->flags = tr->multi_attach.old_flags;
> + ret = bpf_trampoline_update_fentry(tr, orig_flags, failed_addr, old_addr);
> + WARN_ONCE(ret, "bpf_trampoline_update_fentry failed: %d\n", ret);
> + }
> +
> if (tr->cur_image)
> bpf_tramp_image_put(tr->cur_image);
> tr->cur_image = tr->multi_attach.old_image;
> @@ -1643,6 +1666,7 @@ static void bpf_trampoline_multi_attach_rollback(struct bpf_trampoline *tr)
> for_each_mnode_cnt(mnode, link, link->nodes_cnt)
>
> int bpf_trampoline_multi_attach(struct bpf_prog *prog, u32 *ids,
> + u64 *keys, struct bpf_prog **progs,
> struct bpf_tracing_multi_link *link)
> {
> struct bpf_tracing_multi_data *data = &link->data;
> @@ -1651,18 +1675,18 @@ int bpf_trampoline_multi_attach(struct bpf_prog *prog, u32 *ids,
> struct bpf_tracing_multi_node *mnode;
> struct bpf_trampoline *tr;
> int i, err, rollback_cnt;
> - u64 key;
>
> for_each_mnode(mnode, link) {
> rollback_cnt = i;
>
> - err = bpf_check_attach_btf_id_multi(btf, prog, ids[i], &tgt_info);
> + if (progs)
> + err = bpf_check_attach_target(NULL, prog, progs[i], ids[i], &tgt_info);
> + else
> + err = bpf_check_attach_btf_id_multi(btf, prog, ids[i], &tgt_info);
> if (err)
> goto rollback_put;
>
> - key = bpf_trampoline_compute_key(NULL, btf, ids[i]);
> -
> - tr = bpf_trampoline_get(key, &tgt_info);
> + tr = bpf_trampoline_get(keys[i], &tgt_info);
> if (!tr) {
> err = -ENOMEM;
> goto rollback_put;
> @@ -1691,6 +1715,9 @@ int bpf_trampoline_multi_attach(struct bpf_prog *prog, u32 *ids,
> for_each_mnode(mnode, link) {
> bpf_trampoline_multi_attach_init(mnode->trampoline);
>
> + if (progs && progs[i]->aux->tail_call_reachable)
> + mnode->trampoline->flags |= BPF_TRAMP_F_TAIL_CALL_CTX;
> +
> data->entry = &mnode->entry;
> err = __bpf_trampoline_link_prog(&mnode->node, mnode->trampoline, NULL,
> &trampoline_multi_ops, data);
IIUC for bpf_program targets the actuall attachment is happening in
here, right?
the rest of the function logic won't execute, because there won't
be any data in the reg/noreg/mod hashes..?
you seem to use the tracing_multi API to ease up attachment to multiple
bpf programs and end up with just single link fd for all attachments
I think it'd be cleaner to have separate api or code paths for that
jirka
next prev parent reply other threads:[~2026-08-10 13:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 15:00 [PATCH bpf-next 00/13] bpf: Add tracing_multi link support for bpf progs Leon Hwang
2026-08-09 15:00 ` [PATCH bpf-next 01/13] bpf: Initialize ftrace_managed in bpf_trampoline_get Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 02/13] bpf: Factor out update_fentry_multi helper Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 03/13] bpf: Drop unnecessary ftrace_location() in update_fentry_multi() Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 04/13] bpf: Add tracing_multi link support for bpf progs Leon Hwang
2026-08-10 13:13 ` Jiri Olsa [this message]
2026-08-09 15:01 ` [PATCH bpf-next 05/13] libbpf: " Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 06/13] bpf: Add tracing_multi link fdinfo " Leon Hwang
2026-08-09 16:20 ` bot+bpf-ci
2026-08-09 15:01 ` [PATCH bpf-next 07/13] bpf: Add tracing_multi link info " Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 08/13] selftests/bpf: Add tracing_multi bpf prog attach test Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 09/13] selftests/bpf: Add tracing_multi bpf prog attach failure tests Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 10/13] selftests/bpf: Add tracing_multi bpf prog cookie test Leon Hwang
2026-08-09 16:20 ` bot+bpf-ci
2026-08-09 15:01 ` [PATCH bpf-next 11/13] selftests/bpf: Add tracing_multi bpf prog rollback test Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 12/13] selftests/bpf: Add tracing_multi bpf prog link info test Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 13/13] selftests/bpf: Test tailcall with fentry.multi Leon Hwang
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=annOhedRtHBce3px@krava \
--to=olsajiri@gmail.com \
--cc=a.s.protopopov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=avinash.duduskar@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=eyal.birger@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jordan@jrife.io \
--cc=leon.hwang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=malin89@huawei.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=pulehui@huawei.com \
--cc=qmo@kernel.org \
--cc=rongtao@cestc.cn \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=tanjingguo@huawei.com \
--cc=yatsenko@meta.com \
--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