Re: bpf: missed fentry/fexit invocations due to implicit recursion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx/

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@xxxxxxxxxx:anakryiko/retsnoop.git

jirka



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux