Re: [RFC bpf-next 07/12] bpf: Add support to create tracing multi link
flat view
From: bot+bpf-ci@kernel.org
Date: 2026-02-03 10:13:59
Also in:
bpf
quoted hunk ↗ jump to hunk
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 hunk ↗ jump to hunk
@@ -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?
quoted hunk ↗ jump to hunk
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 hunk ↗ jump to hunk
+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:
+int bpf_tracing_multi_attach(struct bpf_prog *prog, const union bpf_attr *attr)
+{[ ... ]
quoted hunk ↗ jump to hunk
+ 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? --- 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/21625440628 AI-authorship-score: low AI-authorship-explanation: Code style and structure are consistent with established kernel BPF patterns, with typical kernel author conventions in commit message and implementation. issues-found: 2 issue-severity-score: medium issue-severity-explanation: Uninitialized attach_type field causes wrong data to be returned to userspace via fdinfo and bpf_link_info, affecting observability but not causing crashes.