All of lore.kernel.org
 help / color / mirror / Atom feed
From: Davide Miola <davide.miola99@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, bpf <bpf@vger.kernel.org>
Subject: Re: bpf: missed fentry/fexit invocations due to implicit recursion
Date: Wed, 22 Mar 2023 23:45:41 +0100	[thread overview]
Message-ID: <CAMAi7A4e=yJrCBrWMuKGs37LjOMeVAQzBPvMiysG7QW1gL0yHw@mail.gmail.com> (raw)
In-Reply-To: <CAADnVQKxbzULYHhWUr=OQWke-QJt6QkVsO7pVBNpgurQMZPWkQ@mail.gmail.com>

On Wed, 22 Mar 2023 at 23:21, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Mar 22, 2023 at 2:39 PM Davide Miola <davide.miola99@gmail.com> wrote:
> >
> > On Wed, 22 Mar 2023 at 17:06, Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > > On Wed, Mar 22, 2023 at 6:10 AM Jiri Olsa <olsajiri@gmail.com> wrote:
> > > >
> > > > 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
> > >
> > > 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.

Sure, but I'd still have to lookup the element from the map first.
At a minimum it would look something like:

SEC("fentry/ip_queue_xmit")
int BPF_PROG(entry_prog) {
    int key = 0;
    int64_t *guard = bpf_map_lookup_elem(&per_cpu, &key);
    if (guard) {
        if (__sync_fetch_and_add(guard, 1) == 0) {
            ...
        }
    }
}

The program could be interrupted before it reaches
__sync_fetch_and_add (just tested this and it does not solve the
problem)

  reply	other threads:[~2023-03-22 22:45 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
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 [this message]
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='CAMAi7A4e=yJrCBrWMuKGs37LjOMeVAQzBPvMiysG7QW1gL0yHw@mail.gmail.com' \
    --to=davide.miola99@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=olsajiri@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.