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?
> goto out;
> }
>
> --
> 2.47.0
>
>
