From: Jiri Olsa <olsajiri@gmail.com>
To: Davide Miola <davide.miola99@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, bpf@vger.kernel.org
Subject: Re: bpf: missed fentry/fexit invocations due to implicit recursion
Date: Wed, 22 Mar 2023 13:57:10 +0100 [thread overview]
Message-ID: <ZBr7Jt9+yr0PHk6K@krava> (raw)
In-Reply-To: <CAMAi7A7Y=m=i-yEOuh-sO-5R5zEGQuo1VwOLKsgvFcv4RRhbhQ@mail.gmail.com>
On Wed, Mar 22, 2023 at 08:33:18AM +0100, Davide Miola wrote:
> > seems correct to me, can you see see recursion_misses counter in
> > bpftool prog output for the entry tracing program?
>
> Indeed I can. The problem here is that the recursion is not triggered
> by my programs; from my point of view any miss is basically a random
> event, and the fact that entry and exit progs can miss independently
> means that, at any point, I can count two exits for one entry or
> (worse) just one exit for two entries, making the whole mechanism
> wildly unreliable.
>
> Would using kprobes/kretprobes instead of fentry/fexit here be my
> best compromise? It is my understanding (please correct me if I'm
> wrong) that kprobes' recursion prevention is per-cpu rather than
> per-program, so in this case there would be no imbalance in the
> number of misses between the entry and exit probes.
kprobes are guarded with perf-cpu bpf_prog_active variable, which will
block nested kprobe calls while kprobe program is running, so you will
get balanced counts but likely miss some executions
there was discussion about this some time ago:
https://lore.kernel.org/bpf/CAEf4BzZ-xe-zSjbBpKLHfQKPnTRTBMA2Eg382+_4kQoTLnj4eQ@mail.gmail.com/
seems the 'active' problem andrii described fits to your case as well
also retsnoop is probably using some custom per-cpu logic in each program
to prevent this issue, you check it in here:
git@github.com:anakryiko/retsnoop.git
jirka
next prev parent reply other threads:[~2023-03-22 12:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-21 17:13 bpf: missed fentry/fexit invocations due to implicit recursion Davide Miola
2023-03-21 22:55 ` Jiri Olsa
2023-03-22 7:33 ` Davide Miola
2023-03-22 12:57 ` Jiri Olsa [this message]
2023-03-22 16:06 ` Alexei Starovoitov
2023-03-22 21:39 ` Davide Miola
2023-03-22 22:21 ` Alexei Starovoitov
2023-03-22 22:45 ` Davide Miola
2023-03-22 22:59 ` Alexei Starovoitov
2023-03-23 8:17 ` Davide Miola
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZBr7Jt9+yr0PHk6K@krava \
--to=olsajiri@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=davide.miola99@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.