From: Jiri Olsa <olsajiri@gmail.com>
To: bot+bpf-ci@kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
kafai@fb.com, eddyz87@gmail.com, songliubraving@fb.com,
yhs@fb.com, menglong8.dong@gmail.com, rostedt@kernel.org,
martin.lau@kernel.org, yonghong.song@linux.dev, clm@meta.com,
ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 07/17] bpf: Add bpf_trampoline_multi_attach/detach functions
Date: Sun, 22 Feb 2026 15:34:59 +0100 [thread overview]
Message-ID: <aZsUE6er2DL2E2Rp@krava> (raw)
In-Reply-To: <1e9f20706c4184df2a84a176fd520277f1d2a9bc08f1101b00b34ff415b6158c@mail.kernel.org>
On Fri, Feb 20, 2026 at 10:57:54AM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> > index 2d701bc6e1a5..c32205adfebe 100644
> > --- a/kernel/bpf/trampoline.c
> > +++ b/kernel/bpf/trampoline.c
>
> [ ... ]
>
> > +static int unregister_fentry_multi(struct bpf_trampoline *tr, u32 orig_flags, void *old_addr,
> > + void *ptr)
> > +{
> > + unsigned long addr = (unsigned long) old_addr;
> > + unsigned long ip = ftrace_location(tr->ip);
> > + struct fentry_multi_data *data = ptr;
> > +
> > + if (bpf_trampoline_use_jmp(tr->flags))
> > + addr = ftrace_jmp_set(addr);
> > + return add_ftrace_hash_entry_direct(data->unreg, ip, addr) ? 0 : -ENOMEM;
> > +}
>
> [ ... ]
>
> > +int bpf_trampoline_multi_attach(struct bpf_prog *prog, u32 *ids,
> > + struct bpf_tracing_multi_link *link)
> > +{
> > + struct bpf_attach_target_info tgt_info = {};
> > + struct bpf_tracing_multi_node *mnode;
> > + int j, i, err, cnt = link->nodes_cnt;
> > + struct fentry_multi_data data = {};
> > + struct bpf_trampoline *tr;
> > + u64 key;
> > +
> > + data.reg = alloc_ftrace_hash(FTRACE_HASH_DEFAULT_BITS);
> > + if (!data.reg)
> > + return -ENOMEM;
> > +
> > + data.modify = alloc_ftrace_hash(FTRACE_HASH_DEFAULT_BITS);
> > + if (!data.modify) {
> > + free_ftrace_hash(data.reg);
> > + return -ENOMEM;
> > + }
>
> data.unreg is left as NULL here. In the forward path this is
> fine since only data.reg and data.modify are used, but the
> rollback path can reach unregister_fentry_multi() which calls
> add_ftrace_hash_entry_direct(data->unreg, ...) with a NULL hash.
>
> This happens when rollback_unlink calls
> __bpf_trampoline_unlink_prog() on a trampoline that had no
> other BPF programs before this attach. Removing the only
> program brings total to 0, so bpf_trampoline_update_ops()
> calls ops->unregister_fentry, reaching:
>
> unregister_fentry_multi()
> add_ftrace_hash_entry_direct(data->unreg, ip, addr)
> __add_hash_entry(hash, entry)
> ftrace_hash_key(hash, ...) <-- NULL dereference
>
> Should data.unreg also be allocated here to cover the rollback
> path?
I knew I should have added rollback tests ;-) right, we need the unreg
hash as well.. it's on my todo, will add fix and add tests next version
>
> > +
> > + for (i = 0; i < cnt; i++) {
> > + mnode = &link->nodes[i];
> > + err = bpf_check_attach_target(NULL, prog, NULL, ids[i], &tgt_info);
> > + if (err)
> > + goto rollback_put;
> > +
> > + key = bpf_trampoline_compute_key(NULL, prog->aux->attach_btf, ids[i]);
> > +
> > + tr = bpf_trampoline_get(key, &tgt_info);
> > + if (!tr) {
> > + err = -ENOMEM;
> > + goto rollback_put;
> > + }
> > +
> > + mnode->trampoline = tr;
> > + mnode->node.link = &link->link;
> > + }
>
> After this loop completes, all cnt trampolines have been
> obtained via bpf_trampoline_get() with refcounts incremented.
>
> > +
> > + trampoline_lock_all();
> > +
> > + for (i = 0; i < cnt; i++) {
> > + mnode = &link->nodes[i];
> > + err = __bpf_trampoline_link_prog(&mnode->node, mnode->trampoline, NULL,
> > + &trampoline_multi_ops, &data);
> > + if (err)
> > + goto rollback_unlink;
> > + }
>
> [ ... ]
>
> > +rollback_unlink:
> > + for (j = 0; j < i; j++) {
> > + mnode = &link->nodes[j];
> > + WARN_ON_ONCE(__bpf_trampoline_unlink_prog(&mnode->node, mnode->trampoline,
> > + NULL, &trampoline_multi_ops, &data));
> > + }
> > + trampoline_unlock_all();
> > +
> > +rollback_put:
> > + for (j = 0; j < i; j++)
> > + bpf_trampoline_put(link->nodes[j].trampoline);
>
> When __bpf_trampoline_link_prog() fails at index i in the
> second loop, this falls through from rollback_unlink to
> rollback_put with i still set to the failing index. But all
> cnt trampolines were obtained in the first loop above.
>
> The rollback_put loop only puts trampolines 0..i-1, leaving
> trampolines i..cnt-1 with elevated refcounts that are never
> released.
>
> When rollback_put is reached directly from the first loop
> (bpf_trampoline_get or bpf_check_attach_target failure), the
> j < i bound is correct since only 0..i-1 were obtained.
>
> Could the rollback_unlink path set i = cnt before falling
> through, or use a separate loop bound for the put?
good catch, I think that's a good fix, thnx
jirka
next prev parent reply other threads:[~2026-02-22 14:35 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 10:06 [PATCH bpf-next 00/17] bpf: tracing_multi link Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 01/17] ftrace: Add ftrace_hash_count function Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 02/17] bpf: Use mutex lock pool for bpf trampolines Jiri Olsa
2026-02-20 10:57 ` bot+bpf-ci
2026-02-22 14:33 ` Jiri Olsa
2026-02-20 19:58 ` Alexei Starovoitov
2026-02-22 14:34 ` Jiri Olsa
2026-02-23 19:35 ` Alexei Starovoitov
2026-02-24 12:27 ` Jiri Olsa
2026-02-24 17:13 ` Alexei Starovoitov
2026-02-20 10:06 ` [PATCH bpf-next 03/17] bpf: Add struct bpf_trampoline_ops object Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 04/17] bpf: Add struct bpf_tramp_node object Jiri Olsa
2026-02-20 10:58 ` bot+bpf-ci
2026-02-22 14:34 ` Jiri Olsa
2026-02-20 19:52 ` kernel test robot
2026-02-20 21:05 ` kernel test robot
2026-02-21 3:00 ` kernel test robot
2026-02-20 10:06 ` [PATCH bpf-next 05/17] bpf: Factor fsession link to use struct bpf_tramp_node Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 06/17] bpf: Add multi tracing attach types Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 07/17] bpf: Add bpf_trampoline_multi_attach/detach functions Jiri Olsa
2026-02-20 10:57 ` bot+bpf-ci
2026-02-22 14:34 ` Jiri Olsa [this message]
2026-02-20 10:06 ` [PATCH bpf-next 08/17] bpf: Add support for tracing multi link Jiri Olsa
2026-02-20 10:57 ` bot+bpf-ci
2026-02-22 14:35 ` Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 09/17] bpf: Add support for tracing_multi link cookies Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 10/17] bpf: Add support for tracing_multi link session Jiri Olsa
2026-02-20 10:57 ` bot+bpf-ci
2026-02-22 14:35 ` Jiri Olsa
2026-04-23 8:07 ` XIAO WU
2026-04-23 8:35 ` Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 11/17] libbpf: Add support to create tracing multi link Jiri Olsa
2026-02-20 10:57 ` bot+bpf-ci
2026-02-22 14:36 ` Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 12/17] selftests/bpf: Add tracing multi skel/pattern/ids attach tests Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 13/17] selftests/bpf: Add tracing multi intersect tests Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 14/17] selftests/bpf: Add tracing multi cookies test Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 15/17] selftests/bpf: Add tracing multi session test Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 16/17] selftests/bpf: Add tracing multi attach fails test Jiri Olsa
2026-02-20 10:06 ` [PATCH bpf-next 17/17] selftests/bpf: Add tracing multi attach benchmark test Jiri Olsa
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=aZsUE6er2DL2E2Rp@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=kafai@fb.com \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=menglong8.dong@gmail.com \
--cc=rostedt@kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.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.