From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Alan Maguire <alan.maguire@oracle.com>
Cc: Steven Rostedt <rostedt@kernel.org>,
Florent Revest <revest@google.com>,
Mark Rutland <mark.rutland@arm.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Menglong Dong <menglong8.dong@gmail.com>,
Song Liu <song@kernel.org>
Subject: Re: [PATCHv6 bpf-next 7/9] bpf: Add trampoline ip hash table
Date: Mon, 12 Jan 2026 22:27:51 +0100 [thread overview]
Message-ID: <aWVnVzeqWJBXwBze@krava> (raw)
In-Reply-To: <CAEf4BzYgqWXoKTffa5Y6Xm-nPbL9aFgrStR0GfUs4-88f10EgQ@mail.gmail.com>
On Fri, Jan 09, 2026 at 04:36:41PM -0800, Andrii Nakryiko wrote:
> On Tue, Dec 30, 2025 at 6:51 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > Following changes need to lookup trampoline based on its ip address,
> > adding hash table for that.
> >
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > include/linux/bpf.h | 7 +++++--
> > kernel/bpf/trampoline.c | 30 +++++++++++++++++++-----------
> > 2 files changed, 24 insertions(+), 13 deletions(-)
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 4e7d72dfbcd4..c85677aae865 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -1325,14 +1325,17 @@ struct bpf_tramp_image {
> > };
> >
> > struct bpf_trampoline {
> > - /* hlist for trampoline_table */
> > - struct hlist_node hlist;
> > + /* hlist for trampoline_key_table */
> > + struct hlist_node hlist_key;
> > + /* hlist for trampoline_ip_table */
> > + struct hlist_node hlist_ip;
> > struct ftrace_ops *fops;
> > /* serializes access to fields of this trampoline */
> > struct mutex mutex;
> > refcount_t refcnt;
> > u32 flags;
> > u64 key;
> > + unsigned long ip;
> > struct {
> > struct btf_func_model model;
> > void *addr;
> > diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> > index 789ff4e1f40b..bdac9d673776 100644
> > --- a/kernel/bpf/trampoline.c
> > +++ b/kernel/bpf/trampoline.c
> > @@ -24,9 +24,10 @@ const struct bpf_prog_ops bpf_extension_prog_ops = {
> > #define TRAMPOLINE_HASH_BITS 10
> > #define TRAMPOLINE_TABLE_SIZE (1 << TRAMPOLINE_HASH_BITS)
> >
> > -static struct hlist_head trampoline_table[TRAMPOLINE_TABLE_SIZE];
> > +static struct hlist_head trampoline_key_table[TRAMPOLINE_TABLE_SIZE];
> > +static struct hlist_head trampoline_ip_table[TRAMPOLINE_TABLE_SIZE];
> >
> > -/* serializes access to trampoline_table */
> > +/* serializes access to trampoline tables */
> > static DEFINE_MUTEX(trampoline_mutex);
> >
> > #ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
> > @@ -135,15 +136,15 @@ void bpf_image_ksym_del(struct bpf_ksym *ksym)
> > PAGE_SIZE, true, ksym->name);
> > }
> >
> > -static struct bpf_trampoline *bpf_trampoline_lookup(u64 key)
> > +static struct bpf_trampoline *bpf_trampoline_lookup(u64 key, unsigned long ip)
> > {
> > struct bpf_trampoline *tr;
> > struct hlist_head *head;
> > int i;
> >
> > mutex_lock(&trampoline_mutex);
> > - head = &trampoline_table[hash_64(key, TRAMPOLINE_HASH_BITS)];
> > - hlist_for_each_entry(tr, head, hlist) {
> > + head = &trampoline_key_table[hash_64(key, TRAMPOLINE_HASH_BITS)];
> > + hlist_for_each_entry(tr, head, hlist_key) {
> > if (tr->key == key) {
> > refcount_inc(&tr->refcnt);
> > goto out;
> > @@ -164,8 +165,12 @@ static struct bpf_trampoline *bpf_trampoline_lookup(u64 key)
> > #endif
> >
> > tr->key = key;
> > - INIT_HLIST_NODE(&tr->hlist);
> > - hlist_add_head(&tr->hlist, head);
> > + tr->ip = ftrace_location(ip);
> > + INIT_HLIST_NODE(&tr->hlist_key);
> > + INIT_HLIST_NODE(&tr->hlist_ip);
> > + hlist_add_head(&tr->hlist_key, head);
> > + head = &trampoline_ip_table[hash_64(tr->ip, TRAMPOLINE_HASH_BITS)];
>
> For key lookups we check that there is no existing trampoline for the
> given key. Can it happen that we have two trampolines at the same IP
> but using two different keys?
so multiple keys (different static functions with same name) resolving to
the same ip happened in past and we should now be able to catch those in
pahole, right? CC-ing Alan ;-)
however, that should fail the attachment on ftrace/direct layer
say we have already registered and attached trampoline key1-ip1,
follow-up attachment of trampoline with key2-ip1 will fail on:
bpf_trampoline_update
register_fentry
direct_ops_add
update_ftrace_direct_add
...
/* Make sure requested entries are not already registered. */
fails, because ip1 is already in direct_functions
...
jirka
>
>
>
> > + hlist_add_head(&tr->hlist_ip, head);
> > refcount_set(&tr->refcnt, 1);
> > mutex_init(&tr->mutex);
> > for (i = 0; i < BPF_TRAMP_MAX; i++)
> > @@ -846,7 +851,7 @@ void bpf_trampoline_unlink_cgroup_shim(struct bpf_prog *prog)
> > prog->aux->attach_btf_id);
> >
> > bpf_lsm_find_cgroup_shim(prog, &bpf_func);
> > - tr = bpf_trampoline_lookup(key);
> > + tr = bpf_trampoline_lookup(key, 0);
> > if (WARN_ON_ONCE(!tr))
> > return;
> >
> > @@ -866,7 +871,7 @@ struct bpf_trampoline *bpf_trampoline_get(u64 key,
> > {
> > struct bpf_trampoline *tr;
> >
> > - tr = bpf_trampoline_lookup(key);
> > + tr = bpf_trampoline_lookup(key, tgt_info->tgt_addr);
> > if (!tr)
> > return NULL;
> >
> > @@ -902,7 +907,8 @@ void bpf_trampoline_put(struct bpf_trampoline *tr)
> > * fexit progs. The fentry-only trampoline will be freed via
> > * multiple rcu callbacks.
> > */
> > - hlist_del(&tr->hlist);
> > + hlist_del(&tr->hlist_key);
> > + hlist_del(&tr->hlist_ip);
> > if (tr->fops) {
> > ftrace_free_filter(tr->fops);
> > kfree(tr->fops);
> > @@ -1175,7 +1181,9 @@ static int __init init_trampolines(void)
> > int i;
> >
> > for (i = 0; i < TRAMPOLINE_TABLE_SIZE; i++)
> > - INIT_HLIST_HEAD(&trampoline_table[i]);
> > + INIT_HLIST_HEAD(&trampoline_key_table[i]);
> > + for (i = 0; i < TRAMPOLINE_TABLE_SIZE; i++)
> > + INIT_HLIST_HEAD(&trampoline_ip_table[i]);
> > return 0;
> > }
> > late_initcall(init_trampolines);
> > --
> > 2.52.0
> >
next prev parent reply other threads:[~2026-01-12 21:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 14:50 [PATCHv6 bpf-next 0/9] ftrace,bpf: Use single direct ops for bpf trampolines Jiri Olsa
2025-12-30 14:50 ` [PATCHv6 bpf-next 1/9] ftrace,bpf: Remove FTRACE_OPS_FL_JMP ftrace_ops flag Jiri Olsa
2026-01-10 0:36 ` Andrii Nakryiko
2025-12-30 14:50 ` [PATCHv6 bpf-next 2/9] ftrace: Make alloc_and_copy_ftrace_hash direct friendly Jiri Olsa
2025-12-30 14:50 ` [PATCHv6 bpf-next 3/9] ftrace: Export some of hash related functions Jiri Olsa
2025-12-30 14:50 ` [PATCHv6 bpf-next 4/9] ftrace: Add update_ftrace_direct_add function Jiri Olsa
2025-12-30 14:50 ` [PATCHv6 bpf-next 5/9] ftrace: Add update_ftrace_direct_del function Jiri Olsa
2025-12-30 14:50 ` [PATCHv6 bpf-next 6/9] ftrace: Add update_ftrace_direct_mod function Jiri Olsa
2025-12-30 14:50 ` [PATCHv6 bpf-next 7/9] bpf: Add trampoline ip hash table Jiri Olsa
2026-01-10 0:36 ` Andrii Nakryiko
2026-01-12 21:27 ` Jiri Olsa [this message]
2026-01-13 11:02 ` Alan Maguire
2026-01-13 11:58 ` Jiri Olsa
2025-12-30 14:50 ` [PATCHv6 bpf-next 8/9] ftrace: Factor ftrace_ops ops_func interface Jiri Olsa
2025-12-30 14:50 ` [PATCHv6 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls Jiri Olsa
2026-01-10 0:36 ` Andrii Nakryiko
2026-02-27 17:40 ` Ihor Solodrai
2026-02-27 20:37 ` Jiri Olsa
2026-02-27 21:24 ` Jiri Olsa
2026-02-27 22:00 ` Ihor Solodrai
2026-02-28 20:39 ` Steven Rostedt
2026-03-02 8:08 ` Jiri Olsa
2026-03-02 15:10 ` Steven Rostedt
2026-01-15 18:54 ` [PATCHv6 bpf-next 0/9] ftrace,bpf: Use single direct ops for bpf trampolines Andrii Nakryiko
2026-01-26 9:48 ` Jiri Olsa
2026-01-28 14:48 ` Steven Rostedt
2026-01-28 20:00 ` patchwork-bot+netdevbpf
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=aWVnVzeqWJBXwBze@krava \
--to=olsajiri@gmail.com \
--cc=alan.maguire@oracle.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=menglong8.dong@gmail.com \
--cc=revest@google.com \
--cc=rostedt@kernel.org \
--cc=song@kernel.org \
/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