Re: [RFC PATCH bpf-next v2 3/3] libbpf: Auto-upgrade kprobes to multi-kprobes when supported

[bot+bpf-ci]

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 056bc50a0bbb..7b5f83ce543e 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -11815,6 +11835,25 @@ bpf_program__attach_kprobe_opts(const struct bpf_program *prog,
>  	offset = OPTS_GET(opts, offset, 0);
>  	pe_opts.bpf_cookie = OPTS_GET(opts, bpf_cookie, 0);
>
> +	/* This provides backwards compatibility to programs using kprobe, but
> +	 * have been auto-upgraded to multi kprobe.
> +	 */
> +	if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI &&
> +	    offset == 0 && attach_mode == PROBE_ATTACH_MODE_DEFAULT) {
> +		LIBBPF_OPTS(bpf_kprobe_multi_opts, multi_opts);
> +		const char *syms[1] = { func_name };
> +		__u64 bpf_cookie;
> +
> +		multi_opts.retprobe = OPTS_GET(opts, retprobe, false);
> +		multi_opts.syms = syms;
> +		multi_opts.cnt = 1;
> +		bpf_cookie = OPTS_GET(opts, bpf_cookie, 0);
> +		if (bpf_cookie)
> +			multi_opts.cookies = &bpf_cookie;
> +
> +		return bpf_program__attach_kprobe_multi_opts(prog, NULL, &multi_opts);
> +	}
> +
> +	legacy = determine_kprobe_perf_type() < 0;

What happens when a program was auto-upgraded to
BPF_TRACE_KPROBE_MULTI but the caller passes offset != 0 or
attach_mode == PROBE_ATTACH_MODE_LINK?

The redirect above is skipped, and the code falls through to the
perf_event path, which eventually calls bpf_link_create() with
BPF_PERF_EVENT. The kernel's bpf_prog_attach_check_attach_type()
in link_create() rejects this:

kernel/bpf/syscall.c:bpf_prog_attach_check_attach_type() {
    case BPF_PROG_TYPE_KPROBE:
        if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI &&
            attach_type != BPF_TRACE_KPROBE_MULTI)
            return -EINVAL;
}

This affects callers of the public API
bpf_program__attach_kprobe_opts() who have a SEC("kprobe") program
that was auto-upgraded but then manually attach with offset != 0
(the get_func_ip_test.c case) or with PROBE_ATTACH_MODE_LINK (the
test_attach_probe_manual.c case). The selftests were updated to use
.single, but external users of the API would get a confusing
-EINVAL with no diagnostic.

Would it make sense to add a pr_warn here for the fallthrough case
when expected_attach_type == BPF_TRACE_KPROBE_MULTI, suggesting
SEC("kprobe.single") as a workaround? Something like:

    if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI) {
        pr_warn("prog '%s': kprobe was auto-upgraded to multi but "
                "offset or attach_mode is incompatible; "
                "use SEC(\"kprobe.single\") instead\n",
                prog->name);
        return libbpf_err_ptr(-ENOTSUP);
    }

[ ... ]

> @@ -12269,14 +12308,24 @@ static int attach_kprobe(const struct bpf_program *prog, long cookie, struct bpf
>  	*link = NULL;
>
>  	/* no auto-attach for SEC("kprobe") and SEC("kretprobe") */
> +	if (strcmp(prog->sec_name, "kprobe") == 0 ||
> +	    strcmp(prog->sec_name, "kretprobe") == 0 ||
> +	    strcmp(prog->sec_name, "kprobe.single") == 0 ||
> +	    strcmp(prog->sec_name, "kretprobe.single") == 0)
>  		return 0;

This isn't a bug, but the comment above still says SEC("kprobe")
and SEC("kretprobe") -- should it also mention the .single
variants now that they are handled here?

[ ... ]


---
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/23741893093