On Wed, Mar 22, 2023 at 2:39 PM Davide Miola <davide.miola99@xxxxxxxxx> wrote: > > On Wed, 22 Mar 2023 at 17:06, Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > On Wed, Mar 22, 2023 at 6:10 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > > > > > 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 > > > > I suspect per-cpu recursion counter will miss more events in this case, > > since _any_ kprobe on that cpu will be blocked. > > If missing events is not an issue you probably want a per-cpu counter > > that is specific to your single ip_queue_xmit attach point. > > The difference between the scenario described in the linked thread > and mine is also the reason why I think in-bpf solutions like a > per-cpu guard can't work here: my programs are recursing due to irqs > interrupting them and invoking ip_queue_xmit, not because some helper > I'm using ends up calling ip_queue_xmit. Recursion can happen > anywhere in my programs, even before they get the chance to set a > flag or increment a counter in a per-cpu map, since there is no > atomic "bpf_map_lookup_and_increment" (or is there?) __sync_fetch_and_add() is supported. A bunch of selftests are using it. Or you can use bpf_spin_lock.
