> 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
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22692622038
