linux-kernel - BPF: map 的所有者

Question

这是 who creates map in BPF 的后续行动因为我的新问题与该线程没有直接关系。

因此，在我看来，必须有一个创建 BPF 映射的点，它是 bpf 程序或加载 bpf 等的用户程序。

BPF 程序必须在编译时知道它将使用的映射类型，所以我们需要:

struct bpf_map_def SEC("maps") my_map = {
...
};

所以它意味着一个用户程序，例如 bpftool ，将开始创建在 bpf ELF 部分中找到的映射，如 who creates map in BPF 中所示线。

另一方面，用户应用程序将需要在 map 中添加/删除条目。为此，它必须知道 map 的 ID为了获得 map 的fd bpf_map_get_fd_by_id()来自 libbpf .之后我们可以享受 bpf_map_update_elem()和类似的 API。

另一方面，如果我们在 BPF 程序中声明了一个 map 部分并且确实使用了 map API，则 map(s) 将保留在内核中并分配 ID。

因此，在这种情况下，我们将有两个具有两个不同 ID 的 map :一个是作为 bpf_prog_load() 的结果创建的。来自 bpftool ，另一个来自用户应用程序的 bpf_create_map() (假设应用程序继续运行，例如更新 map ，并且不返回 shell)。

一定有办法绕过这种歧义吗？

Answer 1

我不完全确定我理解你的问题，让我试着改写一下。

你用 bpftool 加载一个 eBPF 程序，它创建程序所需的所有 map 。 bpftool是一个用户空间应用程序，并最终使用 bpf(BPF_MAP_CREATE, …) 创建 map 系统调用。

你有另一个用户空间应用程序foobar与这些映射交互，可能通过使用 libbpf(最终执行 bpf(BPF_MAP_*, …) 系统调用)从映射中查找、更新或删除元素。

据我了解，第二个申请 foobar还尝试创建 map 。因此，bpftool 创建的 map 之间存在冲突。和 foobar 创建的那个.

如果这是正确的，则解决方案很“简单”:不要创建两次 map 。

这意味着您应该删除对 bpf_create_map() 的调用。从您的其他应用程序 foobar , 或使用 bpftool 以外的其他内容加载程序.通常，工作流包括在 eBPF 目标文件中描述的映射，并由加载程序的同一应用程序在加载之前创建——这就是 bpftool做。然后应用程序拥有 map 的文件描述符并且可以使用它。

或者，可以将映射固定在 BPF 虚拟文件系统 ( /sys/fs/bpf/) 下，以便另一个应用程序可以检索文件描述符，并访问此映射。这是通过系统调用 bpf(BPF_OBJ_GET, …) 完成的。 (目前尚未在手册页上记录，至少在我的系统上)。

如果我是正确的，使用固定 map 还可以允许在加载新的 eBPF 程序时重用已经存在的 map 。我相信 tc如果所描述的 map 存在并且已经固定(参见文件 lib/bpf.c ，但代码并不完全易于阅读)，则包 iproute2 打算这样做。这通常会在重定位时执行。

最近添加了 Maps ID，主要用于调试或自省(introspection)，但在您的情况下，它们可能提供另一种方法来将文件描述符检索到 map ，正如您在 bpf_map_get_fd_by_id() 中描述的那样.尽管您必须首先找到一种获取ID的方法。

希望这可以帮助!