ebpf中的percpu map的注意事项与剖析

1 背景

    故事还要从一次翻车现场说起。

    为了统计各个CPU上的系统调用数据按照cpu分别进行统计，我参考了kernel Documents中关于percpu map的一段原话：

Values stored in BPF_MAP_TYPE_ARRAY can be accessed by multiple programs across different CPUs. To restrict storage to a single CPU, you may use a BPF_MAP_TYPE_PERCPU_ARRAY.

    用我不太靠谱的英语人肉翻译了一下，最后抓住了关键字"you may use a BPF_MAP_TYPE_PERCPU_ARRAY"，我毫不犹豫的选择了BPF_MAP_TYPE_PERCPU_ARRAY作为数据的存储载体。

    接下来就是编写一个最简单的代码框架，然后慢慢完善、打磨功能。谁知刚刚代码框架刚刚写好，结果一跑程序就崩溃了(segfault. 我是幸运的，其实是偶现，如果没有撞见可能程序上线前我都发现不了这个问题)。几经周折，异常引发的范围缩小到bpf_map_lookup_elem(map_fd, &cpu, &value)这个调用引发，而且将BPF_MAP_TYPE_PERCPU_ARRAY换成BPF_MAP_TYPE_ARRAY就再也不出现了。

    这是为什么呢，难道是我用的不对？为了找到原因，接下来就开始了漫长的PERCPU map的探索之路。

    这里补充一些bpf_map_lookup_elem()的知识，以免一些同学一头雾水。

    bpf_map_lookup_elem()是ebpf中查找map中特定key对应value的函数。这个函数存在于两个不同的形态：1) 内核中提供的helper function，供ebpf程序调用；2) libbpf库中提供的用户态接口，最终是通过系统调用来实现查找key对应的value。

2 自我反省

    在深扒代码我认真思考了一下目前的局势：

    1 使用BPF_MAP_TYPE_ARRAY map时，用户态bpf_map_lookup_elem()不出这个问题；

    2 ebpf中内核使用bpf_map_lookup_elem()的helper function为什么就没有问题.

    带着两个问题我深深的怀疑BPF_MAP_TYPE_PERCPU_ARRAY类型的map对于bpf_map_look_elem()的实现在内核helper function和用户态在系统调用上的实现上是不一致的。

3 分析bpf_map_lookup_elem的实现

    为了搞清楚BPF_MAP_TYPE_PERCPU_ARRAY map在bpf_map_look_elem()函数上对于内核helper function和用户态syscall的区别，我开始了这两种方式的探索。

3.1 内核helper function的实现

    可以很清楚的看到，内核helper function在根据key查找元素时最终是通过this_cpu_ptr()获取元素指针。

 3. 2 用户态系统调用

    可以看到，这里最终是拷贝了num_possible_cpus()*元素size 大小的内存到用户态。这里和helper function是有区别的；上面helper function只访问了一个元素大小的内存，而这里则是num_possible_cpus()个元素，也就是说对于BPF_MAP_TYPE_PERCPU_ARRAY这种percpu 类型的map，用户态通过系统调用bpf_map_look_elem()去访问时，需要传递num_possible_cpus()个元素大小的内存来存放内核拷贝的数据。如果只是按照普通MAP方式，传递一个元素大小的内存，则会发生越界。

总结

    本文只是浅浅的关注了一下Linux中BPF_MAP_TYPE_PERCPU_ARRAY类型map在bpf_map_look_elem()函数上对于helper function和用户态系统调用的区别。

    其实在Linux中BPF_MAP_TYPE_PERCPU_ARRAY只是其中一种percpu map，还有其他若干种percpu map，其元素的访问原理也是一样，helper function与用户态系统调用是有区别的。