Linux 5.15内核：用户态bpf_map_delete_elem对应kprobe寻找

核心结论 #

Linux 5.15内核中不存在直接对应用户态bpf_map_delete_elem调用的专属kprobe探测点，这是由用户态bpf_map_delete_elem的实现逻辑决定的。

原因说明 #

• 用户态bpf_map_update_elem能找到bpf_map_update_value.isra.0这类kprobe，是因为该函数编译时生成了带isra优化后缀的导出符号，属于可被kprobe捕获的独立函数实体。
• 而用户态bpf_map_delete_elem的实现非常简洁：它直接封装了bpf()系统调用（传入BPF_MAP_DELETE_ELEM命令），没有生成类似的独立优化符号，因此无法通过常规函数名的kprobe触发。

替代监控方案 #

1. 监控bpf()系统调用 #

通过kprobe追踪用户态发起的bpf系统调用，判断命令类型是否为BPF_MAP_DELETE_ELEM：

bpftrace -e 'kprobe:sys_bpf { if (arg0 == 2) { printf("用户态触发bpf_map_delete_elem操作\n"); } }'

注：BPF_MAP_DELETE_ELEM的数值可能随内核版本微调，可查看内核头文件uapi/linux/bpf.h确认具体值。

2. 结合内核态探针区分调用来源 #

既然你已经能监控内核态的htab_lru_map_delete_elem，可以通过调用栈判断操作是来自用户态还是内核态：

bpftrace -e 'kprobe:htab_lru_map_delete_elem { @call_stacks[stack] = count(); }'

查看采集到的调用栈，若包含用户态程序的调用帧，即可判定为用户态发起的删除操作。

3. 使用uprobe直接探测用户态函数 #

对用户态依赖的libbpf.so中的bpf_map_delete_elem函数设置uprobe，这是最直接的用户态函数探测方式：

bpftrace -e 'uprobe:/usr/lib/x86_64-linux-gnu/libbpf.so.1:bpf_map_delete_elem { printf("用户态调用bpf_map_delete_elem\n"); }'

注：libbpf.so的路径可能因系统架构或发行版不同而变化，可通过ldd命令检查目标程序的libbpf依赖路径。

内容的提问来源于stack exchange，提问作者MJTony