Skip to contentSkip to conversation

ftrace,bpf: Use single direct ops for bpf trampolines

PATCH Superseded Jiri Olsa 4 participants 16 messages Nov 13, 2025

Subsystems (5)
x86 BPF Tracing BPF core +1 more subsystems

v2 of 6 Superseded Latest is v6 →

lore
Share & tools
lore

Jiri Olsa

author reviewer
#0 lore raw

v2 cover ftrace,bpf: Use single direct ops for bpf trampolines

hi,
while poking the multi-tracing interface I ended up with just one ftrace_ops object to attach all trampolines.

This change allows to use less direct API calls during the attachment changes in the future code, so in effect speeding up the attachment.

In current code we get a speed up from using just a single ftrace_ops object.

- with current code:

Performance counter stats for 'bpftrace -e fentry:vmlinux:ksys_* {} -c true':

     6,364,157,902      cycles:k
       828,728,902      cycles:u
     1,064,803,824      instructions:u                   #    1.28  insn per cycle
    23,797,500,067      instructions:k                   #    3.74  insn per cycle
       4.416004987 seconds time elapsed

       0.164121000 seconds user
       1.289550000 seconds sys

- with the fix:

Performance counter stats for 'bpftrace -e fentry:vmlinux:ksys_* {} -c true':

     6,535,857,905      cycles:k
       810,809,429      cycles:u
     1,064,594,027      instructions:u                   #    1.31  insn per cycle
    23,962,552,894      instructions:k                   #    3.67  insn per cycle
       1.666961239 seconds time elapsed

       0.157412000 seconds user
       1.283396000 seconds sys

The speedup seems to be related to the fact that with single ftrace_ops object we don't call ftrace_shutdown anymore (we use ftrace_update_ops instead) and we skip the synchronize rcu calls (each ~100ms) at the end of that function.

rfc: https://lore.kernel.org/bpf/[email protected]/
v1:  https://lore.kernel.org/bpf/[email protected]/

v2 changes:
- rebased on top fo bpf-next/master plus Song's livepatch fixes [1]
- renamed the API functions [2] [Steven]
- do not export the new api [Steven]
- kept the original direct interface:

I'm not sure if we want to melt both *_ftrace_direct and the new interface into single one. It's bit different in semantic (hence the name change as Steven suggested [2]) and I don't think the changes are not that big so we could easily keep both APIs.

v1 changes:
- make the change x86 specific, after discussing with Mark options for arm64 [Mark]

thanks,
jirka

[1] https://lore.kernel.org/bpf/[email protected]/
[2] https://lore.kernel.org/bpf/[email protected]/
---
Jiri Olsa (8):
ftrace: Make alloc_and_copy_ftrace_hash direct friendly
ftrace: Export some of hash related functions
ftrace: Add update_ftrace_direct_add function
ftrace: Add update_ftrace_direct_del function
ftrace: Add update_ftrace_direct_mod function
bpf: Add trampoline ip hash table
ftrace: Factor ftrace_ops ops_func interface
bpf, x86: Use single ftrace_ops for direct calls

 arch/x86/Kconfig        |   1 +
 include/linux/bpf.h     |   7 ++-
 include/linux/ftrace.h  |  37 ++++++++++++++-
 kernel/bpf/trampoline.c | 199 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
 kernel/trace/Kconfig    |   3 ++
 kernel/trace/ftrace.c   | 326 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
 kernel/trace/trace.h    |   8 ----
 7 files changed, 532 insertions(+), 49 deletions(-)
author reviewer
#1 lore raw

PATCH v2 1/8 ftrace: Make alloc_and_copy_ftrace_hash direct friendly

Make alloc_and_copy_ftrace_hash to copy also direct address for each hash entry.

---
 kernel/trace/ftrace.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)
kernel/trace/ftrace.c +9 -2
index 59cfacb8a5bb..0e3714b796d9 100644
@@ -1186,7 +1186,7 @@ static void __add_hash_entry(struct ftrace_hash *hash,
 }
 
 static struct ftrace_func_entry *
-add_hash_entry(struct ftrace_hash *hash, unsigned long ip)
+add_hash_entry_direct(struct ftrace_hash *hash, unsigned long ip, unsigned long direct)
 {
 	struct ftrace_func_entry *entry;
 
@@ -1195,11 +1195,18 @@ add_hash_entry(struct ftrace_hash *hash, unsigned long ip)
 		return NULL;
 
 	entry->ip = ip;
+	entry->direct = direct;
 	__add_hash_entry(hash, entry);
 
 	return entry;
 }
 
+static struct ftrace_func_entry *
+add_hash_entry(struct ftrace_hash *hash, unsigned long ip)
+{
+	return add_hash_entry_direct(hash, ip, 0);
+}
+
 static void
 free_hash_entry(struct ftrace_hash *hash,
 		  struct ftrace_func_entry *entry)
@@ -1372,7 +1379,7 @@ alloc_and_copy_ftrace_hash(int size_bits, struct ftrace_hash *hash)
 	size = 1 << hash->size_bits;
 	for (i = 0; i < size; i++) {
 		hlist_for_each_entry(entry, &hash->buckets[i], hlist) {
-			if (add_hash_entry(new_hash, entry->ip) == NULL)
+			if (add_hash_entry_direct(new_hash, entry->ip, entry->direct) == NULL)
 				goto free_hash;
 		}
 	}
Signature · 1 line
2.51.1
author reviewer
#2 lore raw

PATCH v2 2/8 ftrace: Export some of hash related functions

In reply to Jiri Olsa

We are going to use these functions in following changes.

---
 include/linux/ftrace.h | 16 ++++++++++++++++
 kernel/trace/ftrace.c  |  7 +++----
 kernel/trace/trace.h   |  8 --------
 3 files changed, 19 insertions(+), 12 deletions(-)
include/linux/ftrace.h +16 -0
index 7ded7df6e9b5..e23e6a859e08 100644
@@ -397,6 +397,22 @@ enum ftrace_ops_cmd {
 typedef int (*ftrace_ops_func_t)(struct ftrace_ops *op, enum ftrace_ops_cmd cmd);
 
 #ifdef CONFIG_DYNAMIC_FTRACE
+
+#define FTRACE_HASH_DEFAULT_BITS 10
+
+struct ftrace_hash {
+	unsigned long		size_bits;
+	struct hlist_head	*buckets;
+	unsigned long		count;
+	unsigned long		flags;
+	struct rcu_head		rcu;
+};
+
+struct ftrace_hash *alloc_ftrace_hash(int size_bits);
+void free_ftrace_hash(struct ftrace_hash *hash);
+struct ftrace_func_entry *add_hash_entry_direct(struct ftrace_hash *hash,
+						unsigned long ip, unsigned long direct);
+
 /* The hash used to know what functions callbacks trace */
 struct ftrace_ops_hash {
 	struct ftrace_hash __rcu	*notrace_hash;
kernel/trace/ftrace.c +3 -4
index 0e3714b796d9..e6ccf572c5f6 100644
@@ -68,7 +68,6 @@
 	})
 
 /* hash bits for specific function selection */
-#define FTRACE_HASH_DEFAULT_BITS 10
 #define FTRACE_HASH_MAX_BITS 12
 
 #ifdef CONFIG_DYNAMIC_FTRACE
@@ -1185,7 +1184,7 @@ static void __add_hash_entry(struct ftrace_hash *hash,
 	hash->count++;
 }
 
-static struct ftrace_func_entry *
+struct ftrace_func_entry *
 add_hash_entry_direct(struct ftrace_hash *hash, unsigned long ip, unsigned long direct)
 {
 	struct ftrace_func_entry *entry;
@@ -1265,7 +1264,7 @@ static void clear_ftrace_mod_list(struct list_head *head)
 	mutex_unlock(&ftrace_lock);
 }
 
-static void free_ftrace_hash(struct ftrace_hash *hash)
+void free_ftrace_hash(struct ftrace_hash *hash)
 {
 	if (!hash || hash == EMPTY_HASH)
 		return;
@@ -1305,7 +1304,7 @@ void ftrace_free_filter(struct ftrace_ops *ops)
 }
 EXPORT_SYMBOL_GPL(ftrace_free_filter);
 
-static struct ftrace_hash *alloc_ftrace_hash(int size_bits)
+struct ftrace_hash *alloc_ftrace_hash(int size_bits)
 {
 	struct ftrace_hash *hash;
 	int size;
kernel/trace/trace.h +0 -8
index 85eabb454bee..62e0ac625f65 100644
@@ -899,14 +899,6 @@ enum {
 	FTRACE_HASH_FL_MOD	= (1 << 0),
 };
 
-struct ftrace_hash {
-	unsigned long		size_bits;
-	struct hlist_head	*buckets;
-	unsigned long		count;
-	unsigned long		flags;
-	struct rcu_head		rcu;
-};
-
 struct ftrace_func_entry *
 ftrace_lookup_ip(struct ftrace_hash *hash, unsigned long ip);
 
Signature · 1 line
2.51.1
author reviewer
#3 lore raw

PATCH v2 3/8 ftrace: Add update_ftrace_direct_add function

In reply to Jiri Olsa

Adding update_ftrace_direct_add function that adds all entries (ip -> addr) provided in hash argument to direct ftrace ops and updates its attachments.

The difference to current register_ftrace_direct is
- hash argument that allows to register multiple ip -> direct entries at once
- we can call update_ftrace_direct_add multiple times on the same ftrace_ops object, becase after first registration with register_ftrace_function_nolock, it uses ftrace_update_ops to update the ftrace_ops object

This change will allow us to have simple ftrace_ops for all bpf direct interface users in following changes.

---
 include/linux/ftrace.h |   7 +++
 kernel/trace/ftrace.c  | 128 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 135 insertions(+)
include/linux/ftrace.h +7 -0
index e23e6a859e08..ded3a306a8b2 100644
@@ -542,6 +542,8 @@ int unregister_ftrace_direct(struct ftrace_ops *ops, unsigned long addr,
 int modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr);
 int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned long addr);
 
+int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash);
+
 void ftrace_stub_direct_tramp(void);
 
 #else
@@ -568,6 +570,11 @@ static inline int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned l
 	return -ENODEV;
 }
 
+int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
+{
+	return -ENODEV;
+}
+
 /*
  * This must be implemented by the architecture.
  * It is the way the ftrace direct_ops helper, when called
kernel/trace/ftrace.c +128 -0

134 lines not on this page · raw message

Signature · 1 line
2.51.1
#4 lore raw

Re: [PATCHv2 bpf-next 3/8] ftrace: Add update_ftrace_direct_add function

Should this stub function have static inline qualifiers? All the other stub functions in this section (ftrace_find_rec_direct, register_ftrace_direct, unregister_ftrace_direct, modify_ftrace_direct…
Quoted 4 lines
include/linux/ftrace.h +0 -0
index e23e6a859..ded3a306a 100644

[ ... ]

include/linux/ftrace.h static inline int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned l · line 580

Quoted 12 lines
include/linux/ftrace.h +5 -0
@@ -568,6 +570,11 @@ static inline int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned l
 	return -ENODEV;
 }
 
+int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
+{
+	return -ENODEV;
+}
+
 /*
  * This must be implemented by the architecture.
  * It is the way the ftrace direct_ops helper, when called

Should this stub function have static inline qualifiers? All the other stub functions in this section (ftrace_find_rec_direct, register_ftrace_direct, unregister_ftrace_direct, modify_ftrace_direct, and modify_ftrace_direct_nolock) use static inline. Without it, this could cause multiple definition linker errors when the header is included in multiple compilation units.

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/19332026793

#5 lore raw

Re: [PATCHv2 bpf-next 3/8] ftrace: Add update_ftrace_direct_add function

Quoted 11 lines · On Thu, Nov 13, 2025 at 01:02:18PM +0000, [email protected] wrote:
Quoted 4 lines
include/linux/ftrace.h +0 -0
index e23e6a859..ded3a306a 100644

[ ... ]

Quoted 4 lines
include/linux/ftrace.h +0 -0
@@ -568,6 +570,11 @@ static inline int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned l
 	return -ENODEV;
 }
 
Quoted 15 lines

include/linux/ftrace.h static inline int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned l · line 580

Quoted 8 lines
include/linux/ftrace.h +5 -0
+int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
+{
+	return -ENODEV;
+}
+
 /*
  * This must be implemented by the architecture.
  * It is the way the ftrace direct_ops helper, when called

Should this stub function have static inline qualifiers? All the other stub functions in this section (ftrace_find_rec_direct, register_ftrace_direct, unregister_ftrace_direct, modify_ftrace_direct, and modify_ftrace_direct_nolock) use static inline. Without it, this could cause multiple definition linker errors when the header is included in multiple compilation units.

yep, also the other ones are missing it, will add.. thanks

jirka

Quoted 7 lines

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/19332026793

author reviewer
#6 lore raw

PATCH v2 4/8 ftrace: Add update_ftrace_direct_del function

In reply to Jiri Olsa

Adding update_ftrace_direct_del function that removes all entries (ip -> addr) provided in hash argument to direct ftrace ops and updates its attachments.

The difference to current unregister_ftrace_direct is
- hash argument that allows to unregister multiple ip -> direct entries at once
- we can call update_ftrace_direct_del multiple times on the same ftrace_ops object, becase we do not need to unregister all entries at once, we can do it gradualy with the help of ftrace_update_ops function

This change will allow us to have simple ftrace_ops for all bpf direct interface users in following changes.

---
 include/linux/ftrace.h |  6 +++
 kernel/trace/ftrace.c  | 99 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 105 insertions(+)
include/linux/ftrace.h +6 -0
index ded3a306a8b2..433c36c3af3b 100644
@@ -543,6 +543,7 @@ int modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr);
 int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned long addr);
 
 int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash);
+int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash);
 
 void ftrace_stub_direct_tramp(void);
 
@@ -575,6 +576,11 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
 	return -ENODEV;
 }
 
+int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
+{
+	return -ENODEV;
+}
+
 /*
  * This must be implemented by the architecture.
  * It is the way the ftrace direct_ops helper, when called
kernel/trace/ftrace.c +99 -0

105 lines not on this page · raw message

Signature · 1 line
2.51.1
#7 lore raw

Re: [PATCHv2 bpf-next 4/8] ftrace: Add update_ftrace_direct_del function

Can this leak new_hash? If hash_sub() succeeds for both filter_hash and new_hash, but then either unregister_ftrace_function() or ftrace_update_ops() fails below, we goto out_unlock without freeing…
Quoted 11 lines
include/linux/ftrace.h +1 -0
index ded3a306a..433c36c3a 100644
@@ -543,6 +543,7 @@ int modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr);
 int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned long addr);
 
 int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash);
+int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash);
 
 void ftrace_stub_direct_tramp(void);

[ ... ]

Quoted 4 lines
kernel/trace/ftrace.c +0 -0
index 311ce6406..345f3fdd2 100644

[ ... ]

Quoted 26 lines
kernel/trace/ftrace.c +26 -0
+int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
+{
+	struct ftrace_hash *new_hash = NULL, *filter_hash = NULL, *free_hash = NULL;
+	struct ftrace_func_entry *del, *entry;
+	unsigned long size, i;
+	int err = -EINVAL;
+
+	if (!hash_count(hash))
+		return 0;
+	if (check_direct_multi(ops))
+		return -EINVAL;
+	if (!(ops->flags & FTRACE_OPS_FL_ENABLED))
+		return -EINVAL;
+	if (direct_functions == EMPTY_HASH)
+		return -EINVAL;
+
+	mutex_lock(&direct_mutex);
+
+	/* Make sure requested entries are already registered. */
+	size = 1 << hash->size_bits;
+	for (i = 0; i < size; i++) {
+		hlist_for_each_entry(entry, &hash->buckets[i], hlist) {
+			del = __ftrace_lookup_ip(direct_functions, entry->ip);
+			if (!del || del->direct != entry->direct)
+				goto out_unlock;
+		}

kernel/trace/ftrace.c int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6448

Quoted 10 lines
kernel/trace/ftrace.c +10 -0
+	}
+
+	err = -ENOMEM;
+	filter_hash = hash_sub(ops->func_hash->filter_hash, hash);
+	if (!filter_hash)
+		goto out_unlock;
+
+	new_hash = hash_sub(direct_functions, hash);
+	if (!new_hash)
+		goto out_unlock;

Can this leak new_hash? If hash_sub() succeeds for both filter_hash and new_hash, but then either unregister_ftrace_function() or ftrace_update_ops() fails below, we goto out_unlock without freeing new_hash. The cleanup code only frees filter_hash:

Quoted 18 lines
kernel/trace/ftrace.c +18 -0
+
+	/* If there's nothing left, we need to unregister the ops. */
+	if (ftrace_hash_empty(filter_hash)) {
+		err = unregister_ftrace_function(ops);
+		/* cleanup for possible another register call */
+		ops->func = NULL;
+		ops->trampoline = 0;
+		ftrace_free_filter(ops);
+		ops->func_hash->filter_hash = NULL;
+	} else {
+		err = ftrace_update_ops(ops, filter_hash, EMPTY_HASH);
+	}
+
+	if (!err) {
+		free_hash = direct_functions;
+		rcu_assign_pointer(direct_functions, new_hash);
+	}
+

kernel/trace/ftrace.c int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6476

Quoted 10 lines
kernel/trace/ftrace.c +10 -0
+ out_unlock:
+	mutex_unlock(&direct_mutex);
+
+	if (free_hash && free_hash != EMPTY_HASH)
+		call_rcu_tasks(&free_hash->rcu, register_ftrace_direct_cb);
+	if (filter_hash)
+		free_ftrace_hash(filter_hash);
+
+	return err;
+}

If err != 0, new_hash remains allocated but is never freed. Should the cleanup code add free_ftrace_hash(new_hash) when it's non-NULL?

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/19332026793

#8 lore raw

Re: [PATCHv2 bpf-next 4/8] ftrace: Add update_ftrace_direct_del function

Quoted 86 lines · On Thu, Nov 13, 2025 at 01:02:21PM +0000, [email protected] wrote:
Quoted 11 lines
include/linux/ftrace.h +1 -0
index ded3a306a..433c36c3a 100644
@@ -543,6 +543,7 @@ int modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr);
 int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned long addr);
 
 int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash);
+int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash);
 
 void ftrace_stub_direct_tramp(void);

[ ... ]

Quoted 4 lines
kernel/trace/ftrace.c +0 -0
index 311ce6406..345f3fdd2 100644

[ ... ]

Quoted 26 lines
kernel/trace/ftrace.c +26 -0
+int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
+{
+	struct ftrace_hash *new_hash = NULL, *filter_hash = NULL, *free_hash = NULL;
+	struct ftrace_func_entry *del, *entry;
+	unsigned long size, i;
+	int err = -EINVAL;
+
+	if (!hash_count(hash))
+		return 0;
+	if (check_direct_multi(ops))
+		return -EINVAL;
+	if (!(ops->flags & FTRACE_OPS_FL_ENABLED))
+		return -EINVAL;
+	if (direct_functions == EMPTY_HASH)
+		return -EINVAL;
+
+	mutex_lock(&direct_mutex);
+
+	/* Make sure requested entries are already registered. */
+	size = 1 << hash->size_bits;
+	for (i = 0; i < size; i++) {
+		hlist_for_each_entry(entry, &hash->buckets[i], hlist) {
+			del = __ftrace_lookup_ip(direct_functions, entry->ip);
+			if (!del || del->direct != entry->direct)
+				goto out_unlock;
+		}

kernel/trace/ftrace.c int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6448

Quoted 10 lines
kernel/trace/ftrace.c +10 -0
+	}
+
+	err = -ENOMEM;
+	filter_hash = hash_sub(ops->func_hash->filter_hash, hash);
+	if (!filter_hash)
+		goto out_unlock;
+
+	new_hash = hash_sub(direct_functions, hash);
+	if (!new_hash)
+		goto out_unlock;

Can this leak new_hash? If hash_sub() succeeds for both filter_hash and new_hash, but then either unregister_ftrace_function() or ftrace_update_ops() fails below, we goto out_unlock without freeing new_hash. The cleanup code only frees filter_hash:

Quoted 23 lines
kernel/trace/ftrace.c +23 -0
+
+	/* If there's nothing left, we need to unregister the ops. */
+	if (ftrace_hash_empty(filter_hash)) {
+		err = unregister_ftrace_function(ops);
+		/* cleanup for possible another register call */
+		ops->func = NULL;
+		ops->trampoline = 0;
+		ftrace_free_filter(ops);
+		ops->func_hash->filter_hash = NULL;
+	} else {
+		err = ftrace_update_ops(ops, filter_hash, EMPTY_HASH);
+	}
+
+	if (!err) {
+		free_hash = direct_functions;
+		rcu_assign_pointer(direct_functions, new_hash);
+	}
+
+ out_unlock:
+	mutex_unlock(&direct_mutex);
+
+	if (free_hash && free_hash != EMPTY_HASH)
+		call_rcu_tasks(&free_hash->rcu, register_ftrace_direct_cb);
Quoted 8 lines

kernel/trace/ftrace.c int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6476

Quoted 5 lines
kernel/trace/ftrace.c +5 -0
+	if (filter_hash)
+		free_ftrace_hash(filter_hash);
+
+	return err;
+}

If err != 0, new_hash remains allocated but is never freed. Should the cleanup code add free_ftrace_hash(new_hash) when it's non-NULL?

yep, that's a miss, will fix

thanks,
jirka

author reviewer
#9 lore raw

PATCH v2 5/8 ftrace: Add update_ftrace_direct_mod function

In reply to Jiri Olsa

Adding update_ftrace_direct_mod function that modifies all entries (ip -> direct) provided in hash argument to direct ftrace ops and updates its attachments.

The difference to current modify_ftrace_direct is:
- hash argument that allows to modify multiple ip -> direct entries at once

This change will allow us to have simple ftrace_ops for all bpf direct interface users in following changes.

---
 include/linux/ftrace.h |  6 ++++
 kernel/trace/ftrace.c  | 68 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 74 insertions(+)
include/linux/ftrace.h +6 -0
index 433c36c3af3b..bacb6d9ab426 100644
@@ -544,6 +544,7 @@ int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned long addr);
 
 int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash);
 int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash);
+int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock);
 
 void ftrace_stub_direct_tramp(void);
 
@@ -581,6 +582,11 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
 	return -ENODEV;
 }
 
+int modify_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock)
+{
+	return -ENODEV;
+}
+
 /*
  * This must be implemented by the architecture.
  * It is the way the ftrace direct_ops helper, when called
kernel/trace/ftrace.c +68 -0

74 lines not on this page · raw message

Signature · 1 line
2.51.1
#10 lore raw

Re: [PATCHv2 bpf-next 5/8] ftrace: Add update_ftrace_direct_mod function

The stub function name doesn't match the declaration. Should this be update_ftrace_direct_mod() instead of modify_ftrace_direct_hash()?
Quoted 13 lines
include/linux/ftrace.h +1 -0
index 433c36c3a..bacb6d9ab 100644
@@ -544,6 +544,7 @@ int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned long addr);
 
 int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash);
 int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash);
+int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock);
 
 void ftrace_stub_direct_tramp(void);
 

include/linux/ftrace.h int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 585

Quoted 4 lines
include/linux/ftrace.h +1 -0
@@ -581,6 +582,11 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
 	return -ENODEV;
 }
 
+int modify_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^

The stub function name doesn't match the declaration. Should this be update_ftrace_direct_mod() instead of modify_ftrace_direct_hash()?

Quoted 4 lines
include/linux/ftrace.h +4 -0
+{
+	return -ENODEV;
+}
+

[ ... ]

Quoted 35 lines
kernel/trace/ftrace.c +27 -0
index 345f3fdd2..627d05b57 100644
@@ -6445,6 +6445,74 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
 	return err;
 }
 
+int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock)
+{
+	struct ftrace_hash *orig_hash = ops->func_hash->filter_hash;
+	struct ftrace_func_entry *entry, *tmp;
+	static struct ftrace_ops tmp_ops = {
+		.func		= ftrace_stub,
+		.flags		= FTRACE_OPS_FL_STUB,
+	};
+	unsigned long size, i;
+	int err;
+
+	if (!hash_count(hash))
+		return 0;
+	if (check_direct_multi(ops))
+		return -EINVAL;
+	if (!(ops->flags & FTRACE_OPS_FL_ENABLED))
+		return -EINVAL;
+	if (direct_functions == EMPTY_HASH)
+		return -EINVAL;
+
+	if (do_direct_lock)
+		mutex_lock(&direct_mutex);
+
+	/* Enable the tmp_ops to have the same functions as the direct ops */
+	ftrace_ops_init(&tmp_ops);
+	tmp_ops.func_hash = ops->func_hash;
+

kernel/trace/ftrace.c int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6484

Quoted 10 lines
kernel/trace/ftrace.c +10 -0
+	err = register_ftrace_function_nolock(&tmp_ops);
+	if (err)
+		goto unlock;
+
+	/*
+	 * Call __ftrace_hash_update_ipmodify() here, so that we can call
+	 * ops->ops_func for the ops. This is needed because the above
+	 * register_ftrace_function_nolock() worked on tmp_ops.
+	 */
+	err = __ftrace_hash_update_ipmodify(ops, orig_hash, orig_hash, true);
                                                                        ^^^^

Does __ftrace_hash_update_ipmodify() accept a fourth argument? The function signature shows it only takes three parameters (ops, old_hash, new_hash). This looks like a compilation error.

Quoted 2 lines
kernel/trace/ftrace.c +2 -0
+	if (err)
+		goto out;

[ ... ]

kernel/trace/ftrace.c int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6538

Quoted 4 lines
kernel/trace/ftrace.c +4 -0
+
+out:
+	/* Removing the tmp_ops will add the updated direct callers to the functions */
+	unregister_ftrace_function(&tmp_ops);
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Can this deadlock when do_direct_lock is true? Looking at the code:

update_ftrace_direct_mod() with do_direct_lock=true

    -> mutex_lock(&direct_mutex)
    -> register_ftrace_function_nolock(&tmp_ops) succeeds
    -> __ftrace_hash_update_ipmodify() fails
    -> goto out (still holding direct_mutex)
    -> unregister_ftrace_function(&tmp_ops)
       -> cleanup_direct_functions_after_ipmodify()
          -> mutex_lock(&direct_mutex) /* deadlock */

The unregister path tries to reacquire direct_mutex that we're already holding.

kernel/trace/ftrace.c int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6546

Quoted 8 lines
kernel/trace/ftrace.c +7 -0
+
+unlock:
+	if (do_direct_lock)
+		mutex_unlock(&direct_mutex);
+	return err;
+}
+
 #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/19332026793

#11 lore raw

Re: [PATCHv2 bpf-next 5/8] ftrace: Add update_ftrace_direct_mod function

Quoted 12 lines · On Thu, Nov 13, 2025 at 01:02:17PM +0000, [email protected] wrote:
Quoted 12 lines
include/linux/ftrace.h +1 -0
index 433c36c3a..bacb6d9ab 100644
@@ -544,6 +544,7 @@ int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned long addr);
 
 int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash);
 int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash);
+int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock);
 
 void ftrace_stub_direct_tramp(void);
 
Quoted 8 lines

include/linux/ftrace.h int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 585

Quoted 5 lines
include/linux/ftrace.h +1 -0
@@ -581,6 +582,11 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
 	return -ENODEV;
 }
 
+int modify_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^

The stub function name doesn't match the declaration. Should this be update_ftrace_direct_mod() instead of modify_ftrace_direct_hash()?

it should, my bad

Quoted 54 lines
Quoted 5 lines
include/linux/ftrace.h +4 -0
+{
+	return -ENODEV;
+}
+

[ ... ]

Quoted 35 lines
kernel/trace/ftrace.c +27 -0
index 345f3fdd2..627d05b57 100644
@@ -6445,6 +6445,74 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
 	return err;
 }
 
+int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock)
+{
+	struct ftrace_hash *orig_hash = ops->func_hash->filter_hash;
+	struct ftrace_func_entry *entry, *tmp;
+	static struct ftrace_ops tmp_ops = {
+		.func		= ftrace_stub,
+		.flags		= FTRACE_OPS_FL_STUB,
+	};
+	unsigned long size, i;
+	int err;
+
+	if (!hash_count(hash))
+		return 0;
+	if (check_direct_multi(ops))
+		return -EINVAL;
+	if (!(ops->flags & FTRACE_OPS_FL_ENABLED))
+		return -EINVAL;
+	if (direct_functions == EMPTY_HASH)
+		return -EINVAL;
+
+	if (do_direct_lock)
+		mutex_lock(&direct_mutex);
+
+	/* Enable the tmp_ops to have the same functions as the direct ops */
+	ftrace_ops_init(&tmp_ops);
+	tmp_ops.func_hash = ops->func_hash;
+

kernel/trace/ftrace.c int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6484

Quoted 10 lines
kernel/trace/ftrace.c +10 -0
+	err = register_ftrace_function_nolock(&tmp_ops);
+	if (err)
+		goto unlock;
+
+	/*
+	 * Call __ftrace_hash_update_ipmodify() here, so that we can call
+	 * ops->ops_func for the ops. This is needed because the above
+	 * register_ftrace_function_nolock() worked on tmp_ops.
+	 */
+	err = __ftrace_hash_update_ipmodify(ops, orig_hash, orig_hash, true);
                                                                        ^^^^
Quoted 3 lines

Does __ftrace_hash_update_ipmodify() accept a fourth argument? The function signature shows it only takes three parameters (ops, old_hash, new_hash). This looks like a compilation error.

the whole patchset is based on bpf-next/master plus Song's livepatch fixes which change modify_ftrace_direct_hash function, it's mentioned in the cover letter

Quoted 22 lines
Quoted 3 lines
kernel/trace/ftrace.c +2 -0
+	if (err)
+		goto out;

[ ... ]

kernel/trace/ftrace.c int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6538

Quoted 4 lines
kernel/trace/ftrace.c +4 -0
+
+out:
+	/* Removing the tmp_ops will add the updated direct callers to the functions */
+	unregister_ftrace_function(&tmp_ops);
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Can this deadlock when do_direct_lock is true? Looking at the code:

update_ftrace_direct_mod() with do_direct_lock=true

    -> mutex_lock(&direct_mutex)
    -> register_ftrace_function_nolock(&tmp_ops) succeeds
    -> __ftrace_hash_update_ipmodify() fails
    -> goto out (still holding direct_mutex)
    -> unregister_ftrace_function(&tmp_ops)
       -> cleanup_direct_functions_after_ipmodify()
          -> mutex_lock(&direct_mutex) /* deadlock */
Quoted 2 lines

The unregister path tries to reacquire direct_mutex that we're already holding.

I don't think this can happen because tmp_ops does not have FTRACE_OPS_FL_IPMODIFY flag set

thanks,
jirka

Quoted 16 lines

kernel/trace/ftrace.c int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6546

Quoted 9 lines
kernel/trace/ftrace.c +7 -0
+
+unlock:
+	if (do_direct_lock)
+		mutex_unlock(&direct_mutex);
+	return err;
+}
+
 #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/19332026793

#12 lore raw

Re: [PATCHv2 bpf-next 5/8] ftrace: Add update_ftrace_direct_mod function

Quoted 83 lines · Jiri Olsa
Quoted 12 lines · On Thu, Nov 13, 2025 at 01:02:17PM +0000, [email protected] wrote:
Quoted 12 lines
include/linux/ftrace.h +1 -0
index 433c36c3a..bacb6d9ab 100644
@@ -544,6 +544,7 @@ int modify_ftrace_direct_nolock(struct ftrace_ops *ops, unsigned long addr);
 
 int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash);
 int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash);
+int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock);
 
 void ftrace_stub_direct_tramp(void);
 
Quoted 8 lines

include/linux/ftrace.h int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 585

Quoted 5 lines
include/linux/ftrace.h +1 -0
@@ -581,6 +582,11 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
    return -ENODEV;
 }
 
+int modify_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^

The stub function name doesn't match the declaration. Should this be update_ftrace_direct_mod() instead of modify_ftrace_direct_hash()?

it should, my bad

Quoted 54 lines
Quoted 5 lines
include/linux/ftrace.h +4 -0
+{
+   return -ENODEV;
+}
+

[ ... ]

Quoted 35 lines
kernel/trace/ftrace.c +27 -0
index 345f3fdd2..627d05b57 100644
@@ -6445,6 +6445,74 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
    return err;
 }
 
+int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, bool do_direct_lock)
+{
+   struct ftrace_hash *orig_hash = ops->func_hash->filter_hash;
+   struct ftrace_func_entry *entry, *tmp;
+   static struct ftrace_ops tmp_ops = {
+           .func           = ftrace_stub,
+           .flags          = FTRACE_OPS_FL_STUB,
+   };
+   unsigned long size, i;
+   int err;
+
+   if (!hash_count(hash))
+           return 0;
+   if (check_direct_multi(ops))
+           return -EINVAL;
+   if (!(ops->flags & FTRACE_OPS_FL_ENABLED))
+           return -EINVAL;
+   if (direct_functions == EMPTY_HASH)
+           return -EINVAL;
+
+   if (do_direct_lock)
+           mutex_lock(&direct_mutex);
+
+   /* Enable the tmp_ops to have the same functions as the direct ops */
+   ftrace_ops_init(&tmp_ops);
+   tmp_ops.func_hash = ops->func_hash;
+

kernel/trace/ftrace.c int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash) · line 6484

Quoted 10 lines
kernel/trace/ftrace.c +10 -0
+   err = register_ftrace_function_nolock(&tmp_ops);
+   if (err)
+           goto unlock;
+
+   /*
+    * Call __ftrace_hash_update_ipmodify() here, so that we can call
+    * ops->ops_func for the ops. This is needed because the above
+    * register_ftrace_function_nolock() worked on tmp_ops.
+    */
+   err = __ftrace_hash_update_ipmodify(ops, orig_hash, orig_hash, true);
                                                                        ^^^^
Quoted 3 lines

Does __ftrace_hash_update_ipmodify() accept a fourth argument? The function signature shows it only takes three parameters (ops, old_hash, new_hash). This looks like a compilation error.

Quoted 3 lines

the whole patchset is based on bpf-next/master plus Song's livepatch fixes which change modify_ftrace_direct_hash function, it's mentioned in the cover letter

Ohh. Will send bpf PR to Linus today and merge into bpf-next afterwards.

author reviewer
#13 lore raw

PATCH v2 6/8 bpf: Add trampoline ip hash table

In reply to Jiri Olsa

Following changes need to lookup trampoline based on its ip address, adding hash table for that.

---
 include/linux/bpf.h     |  7 +++++--
 kernel/bpf/trampoline.c | 30 +++++++++++++++++++-----------
 2 files changed, 24 insertions(+), 13 deletions(-)
include/linux/bpf.h +5 -2
index 09d5dc541d1c..ad86857a8562 100644
@@ -1295,14 +1295,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;
kernel/bpf/trampoline.c +19 -11
index f2cb0b097093..9ca75b22aae0 100644
@@ -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)];
+	hlist_add_head(&tr->hlist_ip, head);
 	refcount_set(&tr->refcnt, 1);
 	mutex_init(&tr->mutex);
 	for (i = 0; i < BPF_TRAMP_MAX; i++)
@@ -799,7 +804,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;
 
@@ -819,7 +824,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;
 
@@ -855,7 +860,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);
@@ -1128,7 +1134,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);
Signature · 1 line
2.51.1
author reviewer
#14 lore raw

PATCH v2 7/8 ftrace: Factor ftrace_ops ops_func interface

In reply to Jiri Olsa

We are going to remove "ftrace_ops->private == bpf_trampoline" setup in following changes.

Adding ip argument to ftrace_ops_func_t callback function, so we can use it to look up the trampoline.

---
 include/linux/ftrace.h  | 2 +-
 kernel/bpf/trampoline.c | 3 ++-
 kernel/trace/ftrace.c   | 6 +++---
 3 files changed, 6 insertions(+), 5 deletions(-)
include/linux/ftrace.h +1 -1
index bacb6d9ab426..d4246d02ea0d 100644
@@ -394,7 +394,7 @@ enum ftrace_ops_cmd {
  *        Negative on failure. The return value is dependent on the
  *        callback.
  */
-typedef int (*ftrace_ops_func_t)(struct ftrace_ops *op, enum ftrace_ops_cmd cmd);
+typedef int (*ftrace_ops_func_t)(struct ftrace_ops *op, unsigned long ip, enum ftrace_ops_cmd cmd);
 
 #ifdef CONFIG_DYNAMIC_FTRACE
 
kernel/bpf/trampoline.c +2 -1
index 9ca75b22aae0..26887a0db955 100644
@@ -33,7 +33,8 @@ static DEFINE_MUTEX(trampoline_mutex);
 #ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
 static int bpf_trampoline_update(struct bpf_trampoline *tr, bool lock_direct_mutex);
 
-static int bpf_tramp_ftrace_ops_func(struct ftrace_ops *ops, enum ftrace_ops_cmd cmd)
+static int bpf_tramp_ftrace_ops_func(struct ftrace_ops *ops, unsigned long ip,
+				     enum ftrace_ops_cmd cmd)
 {
 	struct bpf_trampoline *tr = ops->private;
 	int ret = 0;
kernel/trace/ftrace.c +3 -3
index e701516a4a65..03948ec81434 100644
@@ -2049,7 +2049,7 @@ static int __ftrace_hash_update_ipmodify(struct ftrace_ops *ops,
 				 */
 				if (!ops->ops_func)
 					return -EBUSY;
-				ret = ops->ops_func(ops, FTRACE_OPS_CMD_ENABLE_SHARE_IPMODIFY_SELF);
+				ret = ops->ops_func(ops, rec->ip, FTRACE_OPS_CMD_ENABLE_SHARE_IPMODIFY_SELF);
 				if (ret)
 					return ret;
 			} else if (is_ipmodify) {
@@ -8965,7 +8965,7 @@ static int prepare_direct_functions_for_ipmodify(struct ftrace_ops *ops)
 				if (!op->ops_func)
 					return -EBUSY;
 
-				ret = op->ops_func(op, FTRACE_OPS_CMD_ENABLE_SHARE_IPMODIFY_PEER);
+				ret = op->ops_func(op, ip, FTRACE_OPS_CMD_ENABLE_SHARE_IPMODIFY_PEER);
 				if (ret)
 					return ret;
 			}
@@ -9012,7 +9012,7 @@ static void cleanup_direct_functions_after_ipmodify(struct ftrace_ops *ops)
 
 			/* The cleanup is optional, ignore any errors */
 			if (found_op && op->ops_func)
-				op->ops_func(op, FTRACE_OPS_CMD_DISABLE_SHARE_IPMODIFY_PEER);
+				op->ops_func(op, ip, FTRACE_OPS_CMD_DISABLE_SHARE_IPMODIFY_PEER);
 		}
 	}
 	mutex_unlock(&direct_mutex);
Signature · 1 line
2.51.1
author reviewer
#15 lore raw

PATCH v2 8/8 bpf, x86: Use single ftrace_ops for direct calls

In reply to Jiri Olsa

Using single ftrace_ops for direct calls update instead of allocating ftrace_ops object for each trampoline.

With single ftrace_ops object we can use update_ftrace_direct_* api that allows multiple ip sites updates on single ftrace_ops object.

Adding HAVE_SINGLE_FTRACE_DIRECT_OPS config option to be enabled on each arch that supports this.

At the moment we can enable this only on x86 arch, because arm relies on ftrace_ops object representing just single trampoline image (stored in ftrace_ops::direct_call). Ach that do not support this will continue to use *_ftrace_direct api.

---
 arch/x86/Kconfig        |   1 +
 kernel/bpf/trampoline.c | 166 ++++++++++++++++++++++++++++++++++++----
 kernel/trace/Kconfig    |   3 +
 kernel/trace/ftrace.c   |   7 +-
 4 files changed, 160 insertions(+), 17 deletions(-)
arch/x86/Kconfig +1 -0
index fa3b616af03a..65a2fc279b46 100644
@@ -332,6 +332,7 @@ config X86
 	select SCHED_SMT			if SMP
 	select ARCH_SUPPORTS_SCHED_CLUSTER	if SMP
 	select ARCH_SUPPORTS_SCHED_MC		if SMP
+	select HAVE_SINGLE_FTRACE_DIRECT_OPS	if X86_64 && DYNAMIC_FTRACE_WITH_DIRECT_CALLS
 
 config INSTRUCTION_DECODER
 	def_bool y
kernel/bpf/trampoline.c +150 -16

217 lines not on this page · raw message

kernel/trace/Kconfig +3 -0
index d2c79da81e4f..4bf5beb04a5b 100644
@@ -50,6 +50,9 @@ config HAVE_DYNAMIC_FTRACE_WITH_REGS
 config HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
 	bool
 
+config HAVE_SINGLE_FTRACE_DIRECT_OPS
+	bool
+
 config HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS
 	bool
 
kernel/trace/ftrace.c +6 -1
index 03948ec81434..e223fc196567 100644
@@ -2605,8 +2605,13 @@ unsigned long ftrace_find_rec_direct(unsigned long ip)
 static void call_direct_funcs(unsigned long ip, unsigned long pip,
 			      struct ftrace_ops *ops, struct ftrace_regs *fregs)
 {
-	unsigned long addr = READ_ONCE(ops->direct_call);
+	unsigned long addr;
 
+#ifdef CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS
+	addr = ftrace_find_rec_direct(ip);
+#else
+	addr = READ_ONCE(ops->direct_call);
+#endif
 	if (!addr)
 		return;
 
Signature · 1 line
2.51.1