Re: [PATCH RFC bpf-next 2/4] bpf: Add return prog to kprobe multi

[Jiri Olsa <olsajiri@gmail.com>]

On Thu, Feb 08, 2024 at 11:05:06AM -0800, Alexei Starovoitov wrote:
> On Wed, Feb 7, 2024 at 7:36 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> >
> > In addition it's possible to control the execution of the return probe
> > with the return value of the entry bpf program. If the entry program
> > returns 0 the return probe is installed and executed, otherwise it's
> > skip.
> 
> Let's not sneak in a big change in behavior like this.
> 
> > @@ -2828,8 +2832,8 @@ kprobe_multi_link_handler(struct fprobe *fp, unsigned long fentry_ip,
> >         struct bpf_kprobe_multi_link *link;
> >
> >         link = container_of(fp, struct bpf_kprobe_multi_link, fp);
> > -       kprobe_multi_link_prog_run(link, get_entry_ip(fentry_ip), regs);
> > -       return 0;
> > +       return kprobe_multi_link_prog_run(link, link->link.prog,
> > +                                         get_entry_ip(fentry_ip), regs);
> 
> This is big.
> What motivates this change?

hm, this makes the difference only when the new interface is used, so I
thought about it as part of the new interface.. but right, if existing
programs are attached with new interface and un-aware of this, that might
cause issues

in tetragon we use logic where the entry probe does some filtering and
related return probe either gathers other data or quit based on that
filter result

with this change we can eliminate return probe being triggered completely
when the entry filter does not pass

jirka