Re: [PATCH bpf-next v2] libbpf: Add getter for pointer to data area for internal maps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/27/20 3:26 PM, Toke Høiland-Jørgensen wrote:
Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes:

On Fri, Mar 27, 2020 at 5:58 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:

For internal maps (most notably the maps backing global variables), libbpf
uses an internal mmaped area to store the data after opening the object.
This data is subsequently copied into the kernel map when the object is
loaded.

This adds a getter for the pointer to that internal data store. This can be
used to modify the data before it is loaded into the kernel, which is
especially relevant for RODATA, which is frozen on load. This same pointer
is already exposed to the auto-generated skeletons, so access to it is
already API; this just adds a way to get at it without pulling in the full
skeleton infrastructure.

Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
---
v2:
   - Add per-map getter for data area instead of a global rodata getter for bpf_obj

tools/lib/bpf/libbpf.c   | 9 +++++++++
  tools/lib/bpf/libbpf.h   | 1 +
  tools/lib/bpf/libbpf.map | 1 +
  3 files changed, 11 insertions(+)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 085e41f9b68e..a0055f8908fd 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -6756,6 +6756,15 @@ void *bpf_map__priv(const struct bpf_map *map)
         return map ? map->priv : ERR_PTR(-EINVAL);
  }

+void *bpf_map__data_area(const struct bpf_map *map, size_t *size)

I'm not entirely thrilled about "data_area" name. This is entirely for
providing initial value for maps, so maybe something like
bpf_map__init_value() or something along those lines?

Actually, how about a different API altogether:

bpf_map__set_init_value(struct bpf_map *map, void *data, size_t size)?

Application will have to prepare data of correct size, which will be
copied to libbpf's internal storage. It also doesn't expose any of
internal pointer. I don't think extra memcopy is a big deal here.
Thoughts?

Huh, yeah, that's way better. Why didn't I think of that? Think maybe I
was too focused on doing this the same way the skeleton code is. I'll
send a v3 :)

Could you please add a selftest as well?
I'm not excited about new features without tests.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux