补丁是否真正生效需分层验证：源码改没改、编译用没用、运行载没载、行为变没变。须依次检查文件修改、符号存在、模块重编译、内核日志及功能表现，避免仅依赖patch命令输出。
补丁是否真正生效，不能只看 patch 命令输出 “succeeded”，必须分层验证：源码改没改、编译用没用、运行载没载、行为变没变。
检查补丁是否已写入内核源码
打完补丁后第一件事是确认修改确实落在了文件里，而不是被 patch 自动跳过或静默失败。
- 用
git status（如果在 git 仓库中）看是否有修改未提交的文件，比如fs/proc/meminfo.c - 直接搜索补丁中关键变更点：
grep -n "VmallocTotaltest" fs/proc/meminfo.c（替换成你补丁里实际改的字符串） - 对比前后差异：
git diff HEAD -- fs/proc/meminfo.c或diff -u original.c patched.c - 常见坑：补丁路径带
a/b/前缀但目标目录结构不匹配，导致patch没找到文件而跳过；加-p1参数常能解决
确认编译时实际使用了打过补丁的源码
即使源码改了，如果编译过程没触发重新编译对应模块，或者用了缓存/预编译对象，补丁仍不会进入最终内核镜像。
- 清理再编译：
make clean或至少make mrproper，避免旧.o文件残留 - 编译后检查符号是否存在：
nm vmlinux | grep vmalloc_total（根据补丁改动的函数或变量名调整） - 查看模块构建日志：搜
CC fs/proc/meminfo.o是否出现在make输出中，确认该文件被重编译 - 常见坑：用
make -j并行编译时出错可能被吞掉；建议首次验证用make -j1单线程编译，便于定位失败点
验证运行中的内核是否加载了补丁逻辑
安装新内核并重启后，需从运行态反向确认补丁效果，而非仅依赖版本号。
- 检查内核命令行是否含预期标识：
cat /proc/cmdline | grep rt（对 PREEMPT_RT 补丁）、或grep CONFIG_PREEMPT_RT_FULL /boot/config-$(uname -r) - 读取补丁影响的运行时接口：
cat /proc/meminfo | grep VmallocTotaltest（若补丁修改了该字段名） - 查内核日志是否有补丁引入的打印：
dmesg | grep -i "vmalloc.*test" - 对实时补丁，必须跑
cyclictest -l50000 -m -n -i1000 -h100看最大延迟是否显著下降（如从 150μs 降到 25μs） - 常见坑：忘记更新
GRUB配置或未设默认启动项，uname -r显示的是旧内核；务必reboot后再验证
区分“补丁应用成功”和“功能生效”
很多用户卡在这一步：补丁明明打进了源码、也编译进去了，但业务行为没变化——问题往往不在补丁本身，而在配套配置或依赖链。
- PREEMPT_RT 补丁启用需同时满足：内核配置开启
CONFIG_PREEMPT_RT_FULL=y、启动参数含mitigations=off（某些场景）、关闭 CPU 频率调节器（cpupower frequency-set -g performance） - 安全热补丁（如
canonical-livepatch）需检查服务状态：canonical-livepatch status，且注意它只覆盖 CVE 范围内的函数，不改变内核 ABI - 自定义驱动补丁若涉及硬件，要确认设备树（
.dts）或 ACPI 表已适配，否则内核虽加载模块，但 probe 失败 - 最容易被忽略的一点：补丁可能修复的是某个特定调用路径下的竞态，需构造对应负载（如高并发 mmap + munmap）才能触发并验证修复效果
