【发布时间】:2018-06-15 18:17:34
【问题描述】:
这是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 的 ID 才能从 libbpf 获取带有 bpf_map_get_fd_by_id() 的 map 的 fd。之后我们就可以享受bpf_map_update_elem()和类似的API了。
另一方面,如果我们在 BPF 程序中声明了一个 map 部分并且确实使用了 map API,则 map(s) 将保留在内核中并分配 ID。
因此,在这种情况下,我们将有两个具有两个不同 ID 的映射:一个作为来自 bpftool 的 bpf_prog_load() 创建的结果,另一个来自用户应用程序的 bpf_create_map()(假设应用程序继续正在运行,例如更新地图,并且不返回到 shell)。
一定有办法绕过这种歧义?
【问题讨论】:
标签: linux-kernel bpf