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

[Varun R Mallya]

On Mon, Mar 30, 2026 at 11:47:26AM +0000, bot+bpf-ci@xxxxxxxxxx wrote:
> > +			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);
>     }
Nice catch! I've added a check for that now. 
> [ ... ]
> 
> > @@ -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