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@xxxxxxxxxx> 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
