问题标签 [ebpf]

由于现在在 ebpf 程序中允许有界循环https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=2589726d12a1b12eaaa93c7f1ea64287e383c7a5 验证程序是否仍然检查如果程序控制流是有向无环图，则第一次通过？

如果我最初理解得很好，那么 cBPF 验证器和解释器都在net/core/fiter.c例如sk_run_filter这里https://elixir.bootlin.com/linux/v3.2/source/net/core/filter.c#L112只需转换应用它们的 cBPF 指令在仿真寄存器上和直接在 sk_buff 上。同时sk_chk_filter检查说明是否全部合法。

目前我已经看到 filter.c 中仍然有一个bpf_check_classic函数可以替代旧的sk_chk_filter. 检查后尝试 JIT 程序，如果不可能，下一步是将 cBPF 转换为 eBPF。

问题：

1）最后运行jitted/converted cbpf过滤器的实际调用在net/core/filter.c哪里？

2) 将 cBPF 程序作为 eBPF 程序执行的函数调用序列是什么？

https://github.com/torvalds/linux/blob/33920f1ec5bf47c5c0a1d2113989bdd9dfb3fae9/include/linux/filter.h#L556-L571 这是ebpf后备解释器的实现吗？

当我运行时，sudo bpftool prog show我得到以下输出

但是如果我尝试使用以下命令获取程序的输出

我收到一条错误消息，如下所示：

错误：无法获取 prog 信息 (3)：错误地址

问题：我做错了什么？XD

这个补丁是被合并还是被拒绝？还是讨论刚刚结束而没有发展？也许 seccomp 过滤器可以重写为二叉树这一事实足以不添加对 seccomp 的哈希映射支持？

https://groups.google.com/forum/#!msg/libseccomp/pX6QkVF0F74/ZUJlwI5qAwAJ

是的，我很难关注内核补丁讨论并了解它们是否被合并 XD​​ :(

我有一个关于bpftrace语法的问题，希望有人以前看过。

在查看bpftrace参考文档时，我已经能够成功地跟踪用户应用程序功能。那里没有问题。我想不通的是如何将探针附加到 C++ 方法。

例如，这是我正在使用的语法和错误：

将 bpftrace 探针附加到 C++ 用户应用程序的正确语法是什么？

我现在正在研究 XDP 代码，我对程序如何处理数据包标头的某些部分感到有些困惑。所以！当我查看获取数据包 IP 地址的代码时，它是这样的：

现在这里有一些让我感到困惑的事情：

1. 我认为nh_off是下一个标头的偏移值，所以如果您添加data + nh_off，那不应该带您进入下一个数据包吗？因为据我了解，如果你在数据中添加下一个标头偏移量，则应该有下一个数据包等待处理！

2. 做什么

   (void*)&iph[1]

   究竟是做什么的？我试图猜测这行代码做了几天，但我仍然没有任何线索。

如果我的问题太专心或含糊，我很抱歉。这件事困扰了我一段时间，如果有人能与我分享他们的知识，我将不胜感激。非常感谢你。

刚刚同步到最新的 Linux bpf-next repo (5.3.0) 并尝试编译 samples/bpf 目录。Linux 内核编译良好。这是在 Linux 主机上，默认配置取自 /boot/config-* 并更改为定义 XDP 参数。我确实对构建机器具有 root 访问权限。

这就是我得到的，在目录中没有看到.o。

sudo make samples/bpf/CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh DESCEND objtool

我在 ubuntu VM 中检查了 repo (5.2.0-rc*)，并且在那里构建成功。

我错过了什么？任何指针表示赞赏。

谢谢！

是否可以在不同程序类型之间共享 ebpf 映射。我需要在 tc-bpf 程序和 cgroup bpf 程序之间共享一个映射。如果映射固定到充当全局命名空间的文件系统，这应该是可能的。但是，我还没有这个工作。

该映射由 tc-bpf 程序创建并固定到全局命名空间。由于是 tc-bpf 程序，map 的类型为 struct bpf_elf_map。这个 bpf 程序是通过 iproute2 加载的。

现在，我有一个应该访问此映射的 cgroup bpf 程序，但由于它是通过 user.c (libbpf) 或 bpftool 而不是 iproute 加载的，因此此处定义的映射不能是“bpf_elf_map”，而是结构bpf_map_def。所以在cgroup bpf程序中，同样的map被定义为struct bpf_map_def而不是struct bpf_elf_map。

可能正因为如此，当我转储地图（并且不共享预期的地图）时，cgroup 程序会获得一个新的 map_id，理想情况下，当 bpf 程序共享相同的地图时，这些 bpf 程序将具有与其唯一关联的相同 map_id prog_ids。

当我尝试执行sudo ./mineonlyret加载 ebpf 程序的用户空间程序时，我在 ubuntu 19.04 上收到此错误消息，稍后对其进行描述。我在 ubuntu 18.04 上尝试了相同的配置，并且没有错误。哪个可能是导致此错误的原因？如果您需要更多详细信息，请告诉我。

mineonlyret_user.c

mineonlyret_kern.c

我编译_kern.c

和 _user.c 与

另外在这里我还有一个疑问：为什么如果我使用库的共享版本它不起作用？我的意思是如果我执行

目录树