bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Joe Burton <jevburton.kernel@gmail.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>, Petar Penkov <ppenkov@google.com>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	Joe Burton <jevburton@google.com>
Subject: Re: [RFC PATCH v2 00/13] Introduce BPF map tracing capability
Date: Mon, 4 Oct 2021 22:13:06 -0700	[thread overview]
Message-ID: <20211005051306.4zbdqo3rnecj3hyv@ast-mbp> (raw)
In-Reply-To: <20210929235910.1765396-1-jevburton.kernel@gmail.com>

On Wed, Sep 29, 2021 at 11:58:57PM +0000, Joe Burton wrote:
> From: Joe Burton <jevburton@google.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.

  parent reply	other threads:[~2021-10-05  5:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 23:58 [RFC PATCH v2 00/13] Introduce BPF map tracing capability Joe Burton
2021-09-29 23:58 ` [RFC PATCH v2 01/13] bpf: Add machinery to register map tracing hooks Joe Burton
2021-09-29 23:58 ` [RFC PATCH v2 02/13] bpf: Allow loading BPF_TRACE_MAP programs Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 03/13] bpf: Add list of tracing programs to struct bpf_map Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 04/13] bpf: Define a few bpf_link_ops for BPF_TRACE_MAP Joe Burton
2021-09-30  0:26   ` Eric Dumazet
2021-09-30  1:09     ` Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 05/13] bpf: Enable creation of BPF_LINK_TYPE_MAP_TRACE Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 06/13] bpf: Add APIs to invoke tracing programs Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 07/13] bpf: Register BPF_MAP_TRACE_{UPDATE,DELETE}_ELEM hooks Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 08/13] libbpf: Support BPF_TRACE_MAP Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 09/13] bpf: Add infinite loop check on map tracers Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 10/13] Add bpf_map_trace_{update,delete}_elem() helper functions Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 11/13] bpf: verifier inserts map tracing helper call Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 12/13] bpf: Add selftests for map tracing Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 13/13] bpf: Add real world example " Joe Burton
2021-10-05  5:13 ` Alexei Starovoitov [this message]
2021-10-05 21:47   ` [RFC PATCH v2 00/13] Introduce BPF map tracing capability Joe Burton
2021-10-06 16:41     ` Alexei Starovoitov
2021-10-06 21:05       ` Joe Burton
2021-10-18 23:15         ` Alexei Starovoitov

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211005051306.4zbdqo3rnecj3hyv@ast-mbp \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=jevburton.kernel@gmail.com \
    --cc=jevburton@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ppenkov@google.com \
    --cc=sdf@google.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \


* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).