On Mon, Jan 06, 2025 at 02:26:22PM -0800, Song Liu wrote:
> On Mon, Jan 6, 2025 at 9:50 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
> >
> > When kprobe multi bpf program can't be executed due to recursion check,
> > we currently return 0 (success) to fprobe layer where it's ignored for
> > standard kprobe multi probes.
> >
> > For kprobe session the success return value will make fprobe layer to
> > install return probe and try to execute it as well.
> >
> > But the return session probe should not get executed, because the entry
> > part did not run. FWIW the return probe bpf program most likely won't get
> > executed, because its recursion check will likely fail as well, but we
> > don't need to run it in the first place.. also we can make this clear
> > and obvious.
> >
> > It also affects missed counts for kprobe session program execution, which
> > are now doubled (extra count for not executed return probe).
> >
> > Signed-off-by: Jiri Olsa <jolsa@xxxxxxxxxx>
> > ---
> > kernel/trace/bpf_trace.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 48db147c6c7d..1f3d4b72a3f2 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -2797,7 +2797,7 @@ kprobe_multi_link_prog_run(struct bpf_kprobe_multi_link *link,
> >
> > if (unlikely(__this_cpu_inc_return(bpf_prog_active) != 1)) {
> > bpf_prog_inc_misses_counter(link->link.prog);
> > - err = 0;
> > + err = 1;
>
> nit: Shall we return -EBUSY or some other error code?
it's processed in __fprobe_handler and it's treated as bool, so technically
it does not matter.. but I'd rather keep the 0/1 return values in here,
because it's what the session program is forced to return
thanks,
jirka
