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: 25+ 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:14 ` sashiko-bot
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-09 15:33 ` sashiko-bot
2026-08-10 13:13 ` Jiri Olsa [this message]
2026-08-11 6:12 ` Leon Hwang
2026-08-09 15:01 ` [PATCH bpf-next 05/13] libbpf: " Leon Hwang
2026-08-09 15:21 ` sashiko-bot
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:17 ` sashiko-bot
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:17 ` sashiko-bot
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:21 ` sashiko-bot
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:29 ` sashiko-bot
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 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.