kprobe捕获内核函数参数需按abi从pt_regs寄存器读取：x86_64前6个整型参数在%rdi~%r9，arm64在x0~x7；用户态地址须用probe_kernel_read()安全读取，不可直接解引用；register_kprobe返回-22主因是符号未导出或函数被inline，需查/proc/kallsyms及vmlinux符号表。
怎么用 kprobe 捕获内核函数的入参地址
不能直接读函数参数值，kprobe 的 struct pt_regs * 里只存寄存器快照，x86_64 下前 6 个整型参数在 %rdi、%rsi、%rdx、%rcx、%r8、%r9，浮点参数在 %xmm0~%xmm7；ARM64 则是 x0~x7。你得自己从 regs 里取，不是传参变量名就能直接用。
- 别写
printk("arg1 = %d", arg1)——arg1不是 C 变量，根本不存在 - 查 ABI 文档确认目标函数参数顺序和寄存器映射，比如
sys_openat(int dfd, const char __user *filename, int flags)在 x86_64 上：dfd在%rdi，filename在%rsi - 用户空间地址（如
filename）不能直接printk或解引用，必须用copy_from_user()或probe_kernel_read()安全读取
为什么 register_kprobe() 返回 -22（-EINVAL）
最常见原因是符号未导出或函数被 inlined。内核默认不导出大部分非 syscall 函数的符号，kprobe 注册时找不到地址就失败。
- 先查
/proc/kallsyms：运行grep ' sys_openat$' /proc/kallsyms（注意结尾 $ 防止匹配到sys_openatat）；没输出说明符号不可见 - 如果函数太小，GCC 可能 inline 掉，
objdump -t vmlinux | grep sys_openat看有没有对应符号；没有就换do_sys_open这类更稳定的入口 -
CONFIG_KPROBES_ON_FTRACE=y必须开启，否则部分 CONFIG_OPTIMIZE_INLINING=y 场景下会静默失败
如何安全读取用户态字符串参数（比如 filename）
直接 printk("%s", (char *)regs->si) 会 panic —— 用户地址在 kprobe 上下文不可直接访问，且可能已释放或被换出。
- 用
probe_kernel_read()代替copy_from_user()：后者要求进程上下文，而 kprobe 在中断上下文，probe_kernel_read()更安全 - 先申请栈上 buffer（别超 256 字节），再读最多 255 字节 + 补
\0，避免越界 - 示例片段：
char buf[256];<br>probe_kernel_read(buf, (void *)regs->si, sizeof(buf) - 1);<br>buf[sizeof(buf) - 1] = '\0';<br>printk("filename: %s\n", buf);
kretprobe 怎么拿到函数返回值
返回值在 struct pt_regs * 的 %rax（x86_64）或 x0（ARM64）里，但仅在 handler（即 kp->handler）中有效；entry_handler 拿不到。
-
kretprobe必须配对使用：entry_handler存状态（比如保存入参），handler读regs->ax并结合之前存的数据做关联 - 别在
handler里调用可能 sleep 的函数（如msleep、mutex_lock），kretprobe 执行在软中断上下文 - 返回值是
long类型，负值表示错误码（如-ENOENT），需用IS_ERR_VALUE()判断是否出错
实际调试时，最容易漏掉的是 ABI 寄存器映射和用户地址安全读取这两层转换——看着参数名写代码，一跑就 oops。函数符号是否存在、是否被 inline、是否在 ftrace 支持列表里，这三个点卡住的人最多。
