Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20211102021432.2807760-1-jevburton.kernel@gmail.com> <aa6081aa-9741-be05-8051-e01909662ff1@mojatatu.com>
In-Reply-To: <aa6081aa-9741-be05-8051-e01909662ff1@mojatatu.com>
From:   Joe Burton <jevburton.kernel@gmail.com>
Date:   Wed, 3 Nov 2021 10:12:14 -0700
Message-ID: <CAN22DihBMX=xTMeTQ2-Z8Fa6r=1ynKshbfhFJJ5Jb=-ww_9hDQ@mail.gmail.com>
Subject: Re: [RFC PATCH v3 0/3] Introduce BPF map tracing capability
To:     Jamal Hadi Salim <jhs@mojatatu.com>
Cc:     Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <kafai@fb.com>,
        Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
        John Fastabend <john.fastabend@gmail.com>,
        KP Singh <kpsingh@kernel.org>, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, bpf@vger.kernel.org,
        Petar Penkov <ppenkov@google.com>,
        Stanislav Fomichev <sdf@google.com>,
        Joe Burton <jevburton@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

That's a good point. Since the probe is invoked before the update takes
place, it would not be possible to account for the possibility that the
update failed.

Unless someone wants the `pre update' hook, I'll simply adjust the
existing hooks' semantics so that they are invoked after the update.
As discussed, this better suits the intended use case.

On Wed, Nov 3, 2021 at 3:34 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> On 2021-11-01 22:14, Joe Burton wrote:
> > From: Joe Burton<jevburton@google.com>
> >
> > This is the third version of a patch series implementing map tracing.
> >
> > Map tracing enables executing BPF programs upon BPF map updates. This
> > might be useful to perform upgrades of stateful programs; e.g., tracing
> > programs can propagate changes to maps that occur during an upgrade
> > operation.
> >
> > This version uses trampoline hooks to provide the capability.
> > fentry/fexit/fmod_ret programs can attach to two new functions:
> >          int bpf_map_trace_update_elem(struct bpf_map* map, void* key,
> >                  void* val, u32 flags);
> >          int bpf_map_trace_delete_elem(struct bpf_map* map, void* key);
> >
> > These hooks work as intended for the following map types:
> >          BPF_MAP_TYPE_ARRAY
> >          BPF_MAP_TYPE_PERCPU_ARRAY
> >          BPF_MAP_TYPE_HASH
> >          BPF_MAP_TYPE_PERCPU_HASH
> >          BPF_MAP_TYPE_LRU_HASH
> >          BPF_MAP_TYPE_LRU_PERCPU_HASH
> >
> > The only guarantee about the semantics of these hooks is that they execute
> > before the operation takes place. We cannot call them with locks held
> > because the hooked program might try to acquire the same locks. Thus they
> > may be invoked in situations where the traced map is not ultimately
> > updated.
>
> Sorry, I may have missed something obvious while staring at the patches,
> but:
> Dont you want the notification if the command actually was successful
> on the map? If the command failed for whatever reason theres nothing
> to synchronize? Unless you use that as an indicator to re-read the map?
>
> cheers,
> jamal