Re: [RFC bpf-next 07/12] bpf: Add support to create tracing multi link

On Tue, Feb 03, 2026 at 10:13:58AM +0000, bot+bpf-ci@kernel.org wrote:

quoted

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 68600972a..010785246 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h

[ ... ]

quoted

@@ -1863,6 +1864,10 @@ union bpf_attr {

				};
				__u64		expected_revision;
			} cgroup;
+			struct {
+				__aligned_u64	btf_ids;	/* addresses to attach */
+				__u32		btf_ids_cnt;	/* addresses count */
+			} tracing_multi;

The comments say "addresses to attach" and "addresses count", but the field is
named btf_ids and contains BTF type IDs, not addresses. Should these comments
say "BTF IDs to attach" and "BTF IDs count" instead?

yep, wrong comments, will fix

quoted

diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index f7baeb827..82e625aa0 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c

[ ... ]

quoted

+static void bpf_tracing_multi_link_show_fdinfo(const struct bpf_link *link,
+					       struct seq_file *seq)
+{
+	struct bpf_tracing_multi_link *tr_link =
+		container_of(link, struct bpf_tracing_multi_link, link);
+
+	seq_printf(seq, "attach_type:\t%d\n", tr_link->attach_type);
+}
+
+static int bpf_tracing_multi_link_fill_link_info(const struct bpf_link *link,
+						 struct bpf_link_info *info)
+{
+	struct bpf_tracing_multi_link *tr_link =
+		container_of(link, struct bpf_tracing_multi_link, link);
+
+	info->tracing.attach_type = tr_link->attach_type;
+	return 0;
+}

Both functions above use tr_link->attach_type, but looking at
bpf_tracing_multi_attach() below, this field is never initialized:

quoted

+int bpf_tracing_multi_attach(struct bpf_prog *prog, const union bpf_attr *attr)
+{

[ ... ]

quoted

+	link = kzalloc(struct_size(link, nodes, cnt), GFP_KERNEL);
+	if (!link) {
+		err = -ENOMEM;
+		goto error;
+	}
+
+	link->nodes_cnt = cnt;
+
+	bpf_link_init(&link->link, BPF_LINK_TYPE_TRACING_MULTI,
+		      &bpf_tracing_multi_link_lops, prog, prog->expected_attach_type);

bpf_link_init() sets link->link.attach_type (inside the embedded struct bpf_link),
but struct bpf_tracing_multi_link has a separate attach_type field that remains
zero-initialized from kzalloc.

The show_fdinfo and fill_link_info callbacks read tr_link->attach_type which
will always be 0 (BPF_CGROUP_INET_INGRESS) instead of the actual attach type
(BPF_TRACE_FENTRY_MULTI or BPF_TRACE_FEXIT_MULTI).

Looking at the existing bpf_tracing_link_show_fdinfo() and
bpf_tracing_link_fill_link_info() in kernel/bpf/syscall.c, they use
link->attach_type (the inner struct's field). Should tr_link->attach_type
either be removed and link->attach_type used instead, or should it be
explicitly initialized to prog->expected_attach_type?

right, I'll add linkinfo/fdinfo in separate change, thnx

jirka