为何bpftrace无法追踪f2fs_delete_entry函数？

看起来你遇到的问题可能由几个常见原因导致，咱们一步步来排查：

• 先检查函数名拼写！ 你开头说要追踪f2fs_delete_dentry，但实际执行的bpftrace命令里写的是f2fs_delete_entry——少了一个字母d？这很可能是关键笔误！建议先确认内核符号表里的正确函数名，你可以用这个命令查看：

  grep -r f2fs_delete /proc/kallsyms
  

  如果实际函数名是f2fs_delete_dentry，那替换命令里的函数名再试一次。

• 确认内核是否开启必要的支持特性

  • 首先得保证你的内核编译了F2FS文件系统支持（CONFIG_F2FS_FS=y或=m），同时还要开启kprobe、BPF相关的核心选项：CONFIG_KPROBES=y、CONFIG_BPF_SYSCALL=y、CONFIG_DEBUG_INFO_BTF=y（BPFtrace依赖BTF来解析内核数据结构，这个选项很关键）。你可以用以下命令检查这些配置：

    zcat /proc/config.gz | grep -E "CONFIG_F2FS_FS|CONFIG_KPROBES|CONFIG_BPF_SYSCALL|CONFIG_DEBUG_INFO_BTF"
    

    如果有选项是=n或者没出现，那你可能需要重新编译内核开启这些特性，或者更换支持的内核版本。

• 函数是否被内联编译了？
  如果f2fs_delete_entry是内联函数，kprobe就无法追踪它——因为内联函数不会保留独立的函数入口点，也不会出现在内核符号表中。你可以通过以下命令查看这个函数是否存在于符号表：

  nm /usr/lib/modules/$(uname -r)/build/vmlinux | grep f2fs_delete
  

  如果没有找到对应的函数条目，很大概率它被内联了，这时候可能需要用其他方式（比如追踪调用它的父函数，或者查看是否有相关的内核tracepoint）。

• 有没有实际触发函数调用的操作？
  BPFtrace只会在目标函数被调用时输出内容，你得确保自己在挂载的F2FS分区上执行了会触发f2fs_delete_entry的动作——比如删除文件、清空目录、卸载文件系统前清理目录项等。如果只是运行了BPFtrace但没做任何触发操作，自然不会有输出。

• 权限是否足够？
  运行BPFtrace追踪内核函数需要root权限，你是不是用普通用户身份执行的命令？如果是，试试加上sudo再运行你的BPFtrace命令，权限不足也会导致无法正常追踪。

另外，你用bpftrace -lv "t:f2fs:f2fs_delete_entry"没有输出，说明F2FS并没有提供这个特定的tracepoint——不是所有内核函数都有对应的tracepoint，大部分函数只能通过kprobe来追踪，所以先聚焦解决kprobe的问题。

备注：内容来源于stack exchange，提问作者Jun