调试内核时，最常用的操作之一就是查看符号表，但很多人一上来就撞墙——cat /proc/kallsyms 打出来全是 0。别急着怀疑系统坏了，这是内核主动跟你玩起了捉迷藏。
cat /proc/kallsyms 为什么全是 0？
这当然不是查不到，而是内核故意把地址掩码成了 0000000000000000。从 Linux 2.6.38 起，kptr_restrict 默认被设为 2，连 root 都被挡在门外，看不到真实地址。想临时放行？一条命令搞定：echo 0 > /proc/sys/kernel/kptr_restrict（当然需要 root 权限）。
- 如果希望永久生效，在
/etc/sysctl.conf里加上kernel.kptr_restrict = 0，然后sysctl -p加载配置。 - 注意
kptr_restrict=1的情况：此时只有具备CAP_SYSLOG能力的进程（比如 syslogd 或者用 root 启动的某些调试工具）才能看到真实地址。这意味着普通用户态程序依然被蒙在鼓里。
grep 查函数或变量时总漏匹配？
很多人直接 grep ioctl /proc/kallsyms，结果什么也没找到——原因很简单，符号名经常带着下划线前缀，比如 __do_sys_ioctl，直接搜 ioctl 当然会漏。另外大小写和符号类型字段也可能干扰结果。
- 查函数时，最好用
" T "或" t "过滤文本段：grep " T " /proc/kallsyms | grep -i ioctl - 查全局变量则用
" D "或" d "过滤数据段：grep " D " /proc/kallsyms | grep jiffies - 想忽略前缀差异，可以用正则表达式：
grep -E "(do_sys|__do_sys)_ioctl" /proc/kallsyms - 精简输出的常用组合：
grep -i "printk" /proc/kallsyms | awk '{print $1, $3}'就能只显示地址和符号名。
System.map 和 /proc/kallsyms 到底该用哪个？
这两个不是替代关系，而是静态快照和动态视图的区别。选错了，你拿到的地址可能完全无效，或者找不到模块里的符号。
/proc/kallsyms包含所有已加载模块的符号，实时更新，但受kptr_restrict控制，权限不够就看不到。System.map是编译时生成的静态文件（通常位于/boot/System.map-$(uname -r)），不含模块信息，地址固定，但不反映 KASLR 实际加载偏移。- 调试 panic 日志里的地址时，必须问自己：当时是否启用了 KASLR？如果启用了，
System.map的地址大概率对不上，必须用当时运行中的/proc/kallsyms才能还原。 - 模块开发中要定位本模块符号，
/proc/kallsyms更靠谱；如果只是分析离线 vmlinux 文件，直接用nm vmlinux就好。
kallsyms_lookup_name() 在模块里调用失败？
这个函数从内核 5.7 开始就不再导出，5.12 起彻底移出导出列表。部分发行版（比如 RHEL 8.8+）甚至默认禁用该接口。所以，别再指望直接调用了。
- 如果你仍然想试试，调用前必须检查返回值：
unsigned long addr = kallsyms_lookup_name("unexported_func"); if (!addr) return -EINVAL; - 需要包含头文件
#include（注意不是 - 即使编译通过了，运行时也可能返回 NULL。这不代表符号不存在，而是内核配置禁用了接口，或者没有启用
CONFIG_KALLSYMS。 - 替代方案：改用
/proc/kallsyms解析 + 用户态预读，或者依赖debugfs下的kallsyms接口（如果可用）。
说到底，真正麻烦的不是“怎么查”，而是查到的地址能不能用。KASLR 随机化、模块热插拔、kptr_restrict 级别、内核版本对 kallsyms_lookup_name 的策略变化——这些因素叠加起来，让一次看似简单的符号查找，可能在不同机器、不同启动状态下给出完全不同的结果。
