bpf: tracing_multi link

[kernel-patches-daemon-bpf]

Pull request for series with
subject: bpf: tracing_multi link
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1061586

[kernel-patches-daemon-bpf]

Upstream branch: 05c9b2e
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1061586
version: 1

[kernel-patches-review-bot]

commit bdc3ccfd11ec1172e4813072282fe784aab87148
Author: Jiri Olsa <jolsa@kernel.org>

libbpf: Add bpf_link_create support for tracing_multi link

Adds bpf_link_create() handling for BPF_TRACE_FENTRY_MULTI,
BPF_TRACE_FEXIT_MULTI, and BPF_TRACE_FSESSION_MULTI attach types,
with a new tracing_multi struct in bpf_link_create_opts.

> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c

[ ... ]

> +	case BPF_TRACE_FENTRY_MULTI:
> +	case BPF_TRACE_FEXIT_MULTI:
> +	case BPF_TRACE_FSESSION_MULTI:
> +		attr.link_create.tracing_multi.ids = (__u64) OPTS_GET(opts, tracing_multi.ids, 0);
> +		attr.link_create.tracing_multi.cookies = (__u64) OPTS_GET(opts, tracing_multi.cookies, 0);

Should these use ptr_to_u64() instead of a raw (__u64) cast?
The ids and cookies fields are pointers (__u32 * and __u64 *
respectively), and every other pointer-to-u64 conversion in
bpf_link_create() goes through ptr_to_u64():

    attr.link_create.kprobe_multi.syms = ptr_to_u64(OPTS_GET(...));
    attr.link_create.kprobe_multi.addrs = ptr_to_u64(OPTS_GET(...));
    attr.link_create.uprobe_multi.path = ptr_to_u64(OPTS_GET(...));

The ptr_to_u64() helper casts through (unsigned long) first,
which avoids implementation-defined behavior and compiler
warnings on 32-bit builds.

> +		attr.link_create.tracing_multi.cnt = OPTS_GET(opts, tracing_multi.cnt, 0);
> +		if (!OPTS_ZEROED(opts, tracing_multi))
> +			return libbpf_err(-EINVAL);
> +		break;

---

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

In-Reply-To-Subject: libbpf: Add bpf_link_create support for tracing_multi link
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22692622038

[kernel-patches-review-bot]

commit 6b46ffda52ca7e633378f2852f3405aec6279a58
Author: Jiri Olsa <jolsa@kernel.org>

libbpf: Add support to create tracing multi link

Adds bpf_program__attach_tracing_multi() for attaching tracing
programs to multiple functions via pattern or BTF id array, with
SEC() auto-attach support for fentry.multi, fexit.multi, and
fsession.multi variants.

> The provided <pattern> is used as 'pattern' argument in
> bpf_program__attach_kprobe_multi_opts function.

The function referenced here should be
bpf_program__attach_tracing_multi, not
bpf_program__attach_kprobe_multi_opts. This was noted in v1
review.

> - bpf_program__attach_kprobe_multi_opts must either have
>   pattern with module spec or BTF ids from the module

Same here, should be bpf_program__attach_tracing_multi.

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> +struct bpf_link *
> +bpf_program__attach_tracing_multi(const struct bpf_program *prog, const char *pattern,
> +				  const struct bpf_tracing_multi_opts *opts)
> +{
> +	LIBBPF_OPTS(bpf_link_create_opts, lopts);
> +	__u32 *ids, *free_ids = NULL;
> +	__u64 *cookies;
> +	int prog_fd, link_fd, err, cnt;
> +	struct bpf_link *link;
> +
> +	cnt = OPTS_GET(opts, cnt, 0);
> +	ids = OPTS_GET(opts, ids, NULL);
> +	cookies = OPTS_GET(opts, cookies, NULL);

Should this function validate opts with OPTS_VALID() before
calling OPTS_GET()? The comparable
bpf_program__attach_kprobe_multi_opts() does:

    if (!OPTS_VALID(opts, bpf_kprobe_multi_opts))
        return libbpf_err_ptr(-EINVAL);

Without OPTS_VALID(), a caller passing opts with sz=0 would have
ids, cookies and cnt silently ignored rather than getting -EINVAL
back.

---

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

In-Reply-To-Subject: libbpf: Add support to create tracing multi link
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22692622038

[kernel-patches-review-bot]

commit a419e0b46ab7897e4c1a3770287fd2680f6310b0
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Add support for tracing_multi link fdinfo

Adds fdinfo support for the tracing_multi link type, displaying the
count of attached functions and a table of cookie, BTF ID, and
function symbol for each trampoline node.

> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c

[ ... ]

> +	seq_printf(seq, "%18s %10s %s\n", "cookie", "BTF-id", "func");
> +	for (int i = 0; i < tr_link->nodes_cnt; i++) {
> +		struct bpf_tracing_multi_node *mnode = &tr_link->nodes[i];
> +		u32 btf_id;
> +
> +		bpf_trampoline_unpack_key(mnode->trampoline->key, NULL, &btf_id);
> +		seq_printf(seq, "%18llx %10u %pS\n",
> +			   has_cookies ? tr_link->cookies[i] : 0,
> +			   btf_id, (void *) mnode->trampoline->ip);
                          ^^^^

Should this be %18llu instead of %18llx?  Every other BPF link fdinfo
displays cookies as decimal:

bpf_kprobe_multi_show_fdinfo():
    seq_printf(seq, "%llu\t %pS\n",
               has_cookies ? kmulti_link->cookies[i] : 0, ...);

bpf_uprobe_multi_show_fdinfo():
    seq_printf(seq, "%llu\t %#llx\t %#lx\n",
               umulti_link->uprobes[i].cookie, ...);

bpf_tracing_link_show_fdinfo():
    seq_printf(seq, ... "cookie:\t%llu\n", ...);

With %llx, a cookie value like 255 would print as "ff" here but "255"
in every other BPF link fdinfo.  The hex output also lacks a 0x prefix,
making it ambiguous whether values like "10" are decimal or hex.

> +	}
> +}

[ ... ]

---

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

In-Reply-To-Subject: bpf: Add support for tracing_multi link fdinfo
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22692622038

[kernel-patches-review-bot]

commit c33ca3e534ca332631f346977d7eb0d52267cf98
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Use mutex lock pool for bpf trampolines

Replaces the per-trampoline mutex with a pool of 32 shared mutexes,
where each trampoline is hashed to a pool entry.  This is preparation
for the tracing_multi link which needs to lock many trampolines at once.

> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> --- a/kernel/bpf/trampoline.c
> +++ b/kernel/bpf/trampoline.c

[ ... ]

> @@ -99,12 +127,12 @@ static int bpf_tramp_ftrace_ops_func(struct ftrace_ops *ops, unsigned long ip,
>  	 *   cleanup_direct_functions_after_ipmodify
>  	 *
>  	 * In both cases, direct_mutex is already locked. Use
> -	 * mutex_trylock(&tr->mutex) to avoid deadlock in race condition
> +	 * mutex_trylock(select_trampoline_lock(tr)) to avoid deadlock in race condition
>  	 * (something else is making changes to this same trampoline).
>  	 */
> -	if (!mutex_trylock(&tr->mutex)) {
> -		/* sleep 1 ms to make sure whatever holding tr->mutex makes
> -		 * some progress.
> +	if (!mutex_trylock(select_trampoline_lock(tr))) {
> +		/* sleep 1 ms to make sure whatever holding select_trampoline_lock(tr)
> +		 * makes some progress.
>  		 */

With a pool of 32 mutexes, the trylock can now also fail because a
different trampoline that hashes to the same pool entry holds the lock.
Should the comment say "something else holds the same pool lock" instead
of "something else is making changes to this same trampoline"?

Similarly, the sleep comment says the holder "makes some progress" but
with a pool lock the holder could be operating on an entirely unrelated
trampoline.

---

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

In-Reply-To-Subject: bpf: Use mutex lock pool for bpf trampolines
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22692622038

[kernel-patches-review-bot]

commit 4fa90a264adea3fbb723876bdc816192861cb02b
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Add support for tracing multi link

Adds BPF_LINK_TYPE_TRACING_MULTI, a new link type allowing a single
BPF program to attach to multiple kernel functions identified by BTF
IDs. Introduces bpf_tracing_multi_attach() and link ops for the new
link type.

> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c

[ ... ]

> +int bpf_tracing_multi_attach(struct bpf_prog *prog, const union bpf_attr *attr)
> +{
> +	struct bpf_tracing_multi_link *link = NULL;
> +	struct bpf_link_primer link_primer;
> +	u32 cnt, *ids = NULL;
> +	u32 __user *uids;
> +	int err;
> +
> +	uids = u64_to_user_ptr(attr->link_create.tracing_multi.ids);
> +	cnt = attr->link_create.tracing_multi.cnt;
> +
> +	if (!cnt || !uids)
> +		return -EINVAL;

Should attr->link_create.flags be validated here as well?

Both bpf_kprobe_multi_link_attach() and bpf_uprobe_multi_link_attach()
reject non-zero flags:

kernel/trace/bpf_trace.c:bpf_kprobe_multi_link_attach() {
    ...
    if (attr->link_create.flags)
        return -EINVAL;
    ...
}

Without this check, userspace passing flags != 0 will be silently
accepted, which would prevent using the flags field for future
extensions since old kernels could not be distinguished from new
ones.

> +	if (cnt > MAX_TRACING_MULTI_CNT)
> +		return -E2BIG;

[ ... ]

> +#else
> +
> +int bpf_tracing_multi_attach(struct bpf_prog *prog, const union bpf_attr *attr)
> +{
> +	return -EOPNOTSUPP;
> +}
> +
> +#endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS) && CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS */

Minor: there is a stray ')' after CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
in this comment.

---

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

In-Reply-To-Subject: bpf: Add support for tracing multi link
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22692622038

[kernel-patches-review-bot]

commit 5ab797ce2798643019da3f35fe99c43221c6adb9
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Add bpf_trampoline_multi_attach/detach functions

Adds bpf_trampoline_multi_attach/detach functions for attaching a
tracing BPF program to multiple functions/trampolines at once. Uses
batched ftrace hash operations via a shared direct_ops ftrace_ops.

> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> index e2f4a15886b0..c42bf16b6807 100644
> --- a/kernel/bpf/trampoline.c
> +++ b/kernel/bpf/trampoline.c

[ ... ]

> +int bpf_trampoline_multi_detach(struct bpf_prog *prog, struct bpf_tracing_multi_link *link)
> +{
> +	struct bpf_tracing_multi_node *mnode;
> +	struct fentry_multi_data data = {};
> +	int i, cnt = link->nodes_cnt;
> +
> +	data.unreg  = alloc_ftrace_hash(FTRACE_HASH_DEFAULT_BITS);
> +	data.modify = alloc_ftrace_hash(FTRACE_HASH_DEFAULT_BITS);
> +
> +	if (!data.unreg || !data.modify) {
> +		free_ftrace_hash(data.unreg);
> +		return -ENOMEM;
> +	}

If data.unreg allocation fails but data.modify succeeds, only
free_ftrace_hash(data.unreg) is called (which is a no-op on NULL).
Wouldn't data.modify be leaked in that case?

The attach function handles this correctly by using
free_fentry_multi_data() which frees all three hashes. Could the
detach error path also free data.modify?

> +
> +	trampoline_lock_all();

[ ... ]

---

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

In-Reply-To-Subject: bpf: Add bpf_trampoline_multi_attach/detach functions
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22692622038

[kernel-patches-review-bot]

commit 9a3202a3a6f44c686f0b0a3861d05072359830e3
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Add multi tracing attach types

This adds BPF_TRACE_FENTRY_MULTI and BPF_TRACE_FEXIT_MULTI attach types
with base verifier support. Multi programs use bpf_multi_func as a
placeholder attach target during verification and will use a link-based
attachment interface added in subsequent patches.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d92cf2821657..832a87da5a86 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[ ... ]

> @@ -25173,6 +25181,8 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
>  	case BPF_TRACE_FENTRY:
>  	case BPF_TRACE_FEXIT:
>  	case BPF_TRACE_FSESSION:
> +	case BPF_TRACE_FENTRY_MULTI:
> +	case BPF_TRACE_FEXIT_MULTI:

The new multi types are added to this switch, but earlier in the same
function bpf_check_attach_target() there is a check that prevents
BPF_PROG_TYPE_EXT from targeting fentry/fexit/fsession programs:

kernel/bpf/verifier.c:bpf_check_attach_target() {
    ...
    if (tgt_prog->type == BPF_PROG_TYPE_TRACING &&
        prog_extension &&
        (tgt_prog->expected_attach_type == BPF_TRACE_FENTRY ||
         tgt_prog->expected_attach_type == BPF_TRACE_FEXIT ||
         tgt_prog->expected_attach_type == BPF_TRACE_FSESSION)) {
            bpf_log(log, "Cannot extend fentry/fexit/fsession\n");
            return -EINVAL;
    }
    ...
}

Should BPF_TRACE_FENTRY_MULTI and BPF_TRACE_FEXIT_MULTI be included
in that check as well? The comment above it explains that extending
fentry/fexit programs is blocked to prevent
fentry->extension->fentry->extension call chains. Multi programs map
to BPF_TRAMP_FENTRY/BPF_TRAMP_FEXIT in bpf_attach_type_to_tramp(),
so the same concern would apply.

> @@ -25202,7 +25212,17 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,

[ ... ]

---

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

In-Reply-To-Subject: bpf: Add multi tracing attach types
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22692622038

[kernel-patches-daemon-bpf]

Forwarding comment 4000797115 via email
In-Reply-To: 20260304222141.497203-15-jolsa@kernel.org
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260304222141.497203-15-jolsa@kernel.org/

[kernel-patches-daemon-bpf]

Forwarding comment 4000800259 via email
In-Reply-To: 20260304222141.497203-16-jolsa@kernel.org
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260304222141.497203-16-jolsa@kernel.org/

[kernel-patches-daemon-bpf]

Forwarding comment 4000814434 via email
In-Reply-To: 20260304222141.497203-13-jolsa@kernel.org
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260304222141.497203-13-jolsa@kernel.org/

[kernel-patches-daemon-bpf]

Forwarding comment 4000818367 via email
In-Reply-To: 20260304222141.497203-3-jolsa@kernel.org
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260304222141.497203-3-jolsa@kernel.org/

[kernel-patches-daemon-bpf]

Forwarding comment 4000820971 via email
In-Reply-To: 20260304222141.497203-10-jolsa@kernel.org
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260304222141.497203-10-jolsa@kernel.org/

[kernel-patches-daemon-bpf]

Forwarding comment 4000828037 via email
In-Reply-To: 20260304222141.497203-9-jolsa@kernel.org
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260304222141.497203-9-jolsa@kernel.org/

[kernel-patches-daemon-bpf]

Forwarding comment 4000828848 via email
In-Reply-To: 20260304222141.497203-7-jolsa@kernel.org
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260304222141.497203-7-jolsa@kernel.org/

[kernel-patches-daemon-bpf]

Upstream branch: 4faa189
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1061586
version: 1

[kernel-patches-daemon-bpf]

Upstream branch: 748f9c6
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1061586
version: 1

[kernel-patches-daemon-bpf]

Upstream branch: 6dd780f
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1061586
version: 1

[kernel-patches-daemon-bpf]

Upstream branch: 099bded
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1061586
version: 1

Pull request is NOT updated. Failed to apply https://patchwork.kernel.org/project/netdevbpf/list/?series=1061586
error message:

Cmd('git') failed due to: exit code(128)
  cmdline: git am --3way
  stdout: 'Applying: ftrace: Add ftrace_hash_count function
Applying: bpf: Use mutex lock pool for bpf trampolines
Using index info to reconstruct a base tree...
M	kernel/bpf/trampoline.c
Falling back to patching base and 3-way merge...
Auto-merging kernel/bpf/trampoline.c
CONFLICT (content): Merge conflict in kernel/bpf/trampoline.c
Patch failed at 0002 bpf: Use mutex lock pool for bpf trampolines'
  stderr: 'error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"'

conflict:

diff --cc kernel/bpf/trampoline.c
index f02254a21585,28a5a96bccec..000000000000
--- a/kernel/bpf/trampoline.c
+++ b/kernel/bpf/trampoline.c
@@@ -999,12 -1026,15 +1026,19 @@@ int bpf_trampoline_link_cgroup_shim(str
  	if (!tr)
  		return  -ENOMEM;
  
- 	mutex_lock(&tr->mutex);
+ 	trampoline_lock(tr);
  
  	shim_link = cgroup_shim_find(tr, bpf_func);
 -	if (shim_link) {
 +	if (shim_link && !IS_ERR(bpf_link_inc_not_zero(&shim_link->link.link))) {
  		/* Reusing existing shim attached by the other program. */
++<<<<<<< HEAD
 +		mutex_unlock(&tr->mutex);
++=======
+ 		bpf_link_inc(&shim_link->link.link);
+ 
+ 		trampoline_unlock(tr);
+ 
++>>>>>>> bpf: Use mutex lock pool for bpf trampolines
  		bpf_trampoline_put(tr); /* bpf_trampoline_get above */
  		return 0;
  	}