Message-ID: <CAL0ypaB3=cPnCGdwfEHhSLf8zh_mMJ=mL5T_3EfTsPFbNuLSAA@mail.gmail.com>
Date:   Tue, 5 Oct 2021 14:47:34 -0700
From:   Joe Burton <jevburton@...gle.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Joe Burton <jevburton.kernel@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Petar Penkov <ppenkov@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        Hao Luo <haoluo@...gle.com>, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Subject: Re: [RFC PATCH v2 00/13] Introduce BPF map tracing capability

> It's a neat idea to user verifier powers for this job,
> but I wonder why simple tracepoint in map ops was not used instead?

My concern with tracepoints is that they execute for all map updates,
not for a particular map. Ideally performing an upgrade of program X
should not affect the performance characteristics of program Y.

If n programs are opted into this model, then upgrading any of them
affects the performance characteristics of every other. There's also
the (very remote) possibility of multiple simultaneous upgrades tracing
map updates at the same time, causing a greater performance hit.

> I don't think the "solution" for lookup operation is worth pursuing.
> The bpf prog that needs this map tracing is completely in your control.
> So just don't do writes after lookup.

I eventually want to support apps that use local storage. Those APIs
generally only allow updates via a pointer. E.g. bpf_sk_storage_get()
only allows updates via the returned pointer and via
bpf_sk_storage_delete().

Since I eventually have to solve this problem to handle local storage,
then it seems worth solving it for normal maps as well. They seem
like isomorphic problems.

On Mon, Oct 4, 2021 at 10:13 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Wed, Sep 29, 2021 at 11:58:57PM +0000, Joe Burton wrote:
> > From: Joe Burton <jevburton@...gle.com>
> >
> > This patch introduces 'map tracing': the capability to execute a
> > tracing program after updating a map.
> >
> > Map tracing enables upgrades of stateful programs with fewer race
> > conditions than otherwise possible. We use a tracing program to
> > imbue a map with copy-on-write semantics, then use an iterator to
> > perform a bulk copy of data in the map. After bulk copying concludes,
> > updates to that map automatically propagate via the tracing
> > program, avoiding a class of race conditions. This use case is
> > demonstrated in the new 'real_world_example' selftest.
> >
> > Extend BPF_PROG_TYPE_TRACING with a new attach type, BPF_TRACE_MAP,
> > and allow linking these programs to arbitrary maps.
> >
> > Extend the verifier to invoke helper calls directly after
> > bpf_map_update_elem() and bpf_map_delete_elem(). The helpers have the
> > exact same signature as the functions they trace, and simply pass those
> > arguments to the list of tracing programs attached to the map.
>
> It's a neat idea to user verifier powers for this job,
> but I wonder why simple tracepoint in map ops was not used instead?
> With BTF the bpf progs see the actual types of raw tracepoints.
> If tracepoint has map, key, value pointers the prog will be able
> to access them in read-only mode.
> Such map pointer will be PTR_TO_BTF_ID, so the prog won't be able
> to recursively do lookup/update on this map pointer,
> but that's what you need anyway, right?
> If not we can extend this part of the tracepoint/verifier.
>
> Instead of tracepoint it could have been an empty noinline function
> and fentry/fexit would see all arguments as well.
>
> > One open question is how to handle pointer-based map updates. For
> > example:
> >   int *x = bpf_map_lookup_elem(...);
> >   if (...) *x++;
> >   if (...) *x--;
> > We can't just call a helper function right after the
> > bpf_map_lookup_elem(), since the updates occur later on. We also can't
> > determine where the last modification to the pointer occurs, due to
> > branch instructions. I would therefore consider a pattern where we
> > 'flush' pointers at the end of a BPF program:
> >   int *x = bpf_map_lookup_elem(...);
> >   ...
> >   /* Execute tracing programs for this cell in this map. */
> >   bpf_map_trace_pointer_update(x);
> >   return 0;
> > We can't necessarily do this in the verifier, since 'x' may no
> > longer be in a register or on the stack. Thus we might introduce a
> > helper to save pointers that should be flushed, then flush all
> > registered pointers at every exit point:
> >   int *x = bpf_map_lookup_elem(...);
> >   /*
> >    * Saves 'x' somewhere in kernel memory. Does nothing if no
> >    * corresponding tracing progs are attached to the map.
> >    */
> >   bpf_map_trace_register_pointer(x);
> >   ...
> >   /* flush all registered pointers */
> >   bpf_map_trace_pointer_update();
> >   return 0;
> > This should be easy to implement in the verifier.
>
> I don't think the "solution" for lookup operation is worth pursuing.
> The bpf prog that needs this map tracing is completely in your control.
> So just don't do writes after lookup.
>
> > In addition, we use the verifier to instrument certain map update
> > calls. This requires saving arguments onto the stack, which means that
> > a program using MAX_BPF_STACK bytes of stack could exceed the limit.
> > I don't know whether this actually causes any problems.
>
> Extra 8*4 bytes of stack is not a deal breaker.

Powered by blists - more mailing lists