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 04:53:38PM +0200, Jiri Olsa wrote:
> On Mon, Mar 30, 2026 at 04:30:19PM +0530, Varun R Mallya wrote:
> > +			const char *sec_name = prog->sec_name;
> > +			/* Here, we filter out for k[ret]probe or "k[ret]probe/"
> > +			 * but we leave out anything with an '@'
> > +			 * in it as kprobe_multi does not support versioned
> > +			 * symbols, so we don't upgrade. Also for '+' as we do not
> 
> hum, kprobe versioned symbols?
Thanks for catching that! Removed.
> > +			      (sec_name[9] == '/' || sec_name[9] == '\0'))) &&
> > +			    !strchr(sec_name, '@') &&
> > +			    !strchr( sec_name, '+') &&
> > +			    !(prog->prog_flags & BPF_F_SLEEPABLE))
> 
> is this check necessary?

I had to add that check because selftests/bpf/prog_tests/attach_probe.c
was failing. Sleepable kprobes are not supposed to attach successfully,
but since this was upgraded to multi, it was doing so. So, I had to stop
all sleepable kprobes from being upgraded to maintain compatibility.

I'd like to know if kprobe_multi is even allowed to be sleepable. I
could not really find any selftests or patches for sleepable kprobe_multi
functionality anywhere, so I just want to check if this is not actually
intended behaviour and we are missing a check somewhere.

> > +				prog->expected_attach_type = BPF_TRACE_KPROBE_MULTI;
> > +		}
> > +
> 
> maybe add the upgrade logic into separate function, like
> 
>    static int upgrade_program(struct bpf_program *prog)
I am thinking of making the return type void though.
I see that there is int everywhere else, but it does not make sense to me
to return an int here since I'm not doing any operation in here that
could return an error. Should I keep it as int or make it void ??
> 
> >  		err = bpf_object__sanitize_prog(obj, prog);
> >  		if (err)
> >  			return err;
> > @@ -9924,10 +9942,12 @@ static const struct bpf_sec_def section_defs[] = {
> >  	SEC_DEF("sk_reuseport/migrate",	SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, SEC_ATTACHABLE),
> >  	SEC_DEF("sk_reuseport",		SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT, SEC_ATTACHABLE),
> >  	SEC_DEF("kprobe+",		KPROBE,	0, SEC_NONE, attach_kprobe),
> > +	SEC_DEF("kprobe.single+",	KPROBE,	0, SEC_NONE, attach_kprobe),
> >  	SEC_DEF("uprobe+",		KPROBE,	0, SEC_NONE, attach_uprobe),
> >  	SEC_DEF("uprobe.s+",		KPROBE,	0, SEC_SLEEPABLE, attach_uprobe),
> >  	SEC_DEF("uprobe.single+",	KPROBE,	0, SEC_NONE, attach_uprobe),
> >  	SEC_DEF("kretprobe+",		KPROBE, 0, SEC_NONE, attach_kprobe),
> > +	SEC_DEF("kretprobe.single+",	KPROBE, 0, SEC_NONE, attach_kprobe),
> >  	SEC_DEF("uretprobe+",		KPROBE, 0, SEC_NONE, attach_uprobe),
> >  	SEC_DEF("uretprobe.s+",		KPROBE, 0, SEC_SLEEPABLE, attach_uprobe),
> >  	SEC_DEF("uretprobe.single+",	KPROBE,	0, SEC_NONE, attach_uprobe),
> > @@ -11769,6 +11789,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;
> 
> could we do directly:
> 
> 		multi_opts.syms = &func_name;
> 
> jirka

Implemented.