内核开发干久了最让人头疼的永远是那类不崩机、不报错、只会让内存监控图缓慢下滑的问题。进程泄漏可以抓 RSS、可以重启进程止血甚至拿用户态 profiler 能直接给你定位到具体某一行内核内存泄漏则是另一回事它藏在驱动、缓存、协议栈这些犄角旮旯里往往要等系统挣扎到 OOM 把无辜进程杀掉才有人注意到事情不对。为了把这类问题从玄学变成工程问题我花了两周做了一款内核内存泄漏检测器运行时加载、按调用栈归因、开销可控上线第一周就成功揪出一个网卡驱动在热拔插路径里的泄漏点。这篇文章把整个方案从头拆一遍包括内核泄漏为什么难查、现成工具为什么不够用、检测器怎么设计和实现、实际排查的完整流程以及我踩过的一堆坑。1. 内核内存泄漏的本质为什么用户态经验全部失灵1.1 用户态和内核态的泄漏完全是两种生物用户态的内存泄漏说到底还是有兜底的进程退出或者挂掉内核会把整个地址空间一并回收你最多损失一点业务连续性内存迟早要回来。排查这一侧也有成熟手段RSS、堆快照、分配热点甚至看一眼前端监控就能把嫌疑范围缩到一个进程。内核态完全不是这个套路。内核里每块 kmalloc、每个 slab 对象、每段 vmalloc 区域生命周期都绑定在某个驱动或子系统对象上不存在进程退出就统一回收这种事。谁分配、谁释放漏了就是漏了除非系统重启否则这块内存不会再回到可用池。麻烦的另一个点在于记账粒度。系统级内存统计只能看到 Slab、PageTables、KernelStack 这类聚合桶你看不到是哪个驱动、哪条调用路径把内存吃掉的。用户态泄漏至少还有一份嫌疑人名单内核态泄漏连排查范围都没有——你要在几 GB 的地址空间里找到某个每次只漏几十字节的错误分支。我见过最磨人的一次每笔泄漏只有 64 字节但触发频率是每秒几千次三天下来就是几个 GB而代码层面的问题只是驱动里一个提前 return 的分支少了一句释放调用。1.2 内核泄漏典型的四类藏身处按概率排序我复盘过手头十几个泄漏案例基本逃不出下面四类模式。第一类错误分支漏掉释放最常见也最好修。正常路径上对象用完会走释放流程但某个异常分支里提前 return 了释放代码被整个跳过。这类泄漏单次量级极小但通常和请求频率强相关。如果业务每次调用都稳定触发这个分支累积速度非常快检测器报告里会看到同一调用栈的未释放对象数跟着业务流量一起起跳。第二类引用计数卡死。内核对象普遍靠引用计数管理生命周期refcount 归零才真正释放。某个模块在获取引用之后忘了释放或者获取了两次只释放一次对象就会一直悬在内存里。这类问题比第一类隐蔽因为对象本身可能还在某个链表中正常使用只是永远等不到最后的释放而且往往伴随文件描述符、锁、定时器这些配套资源一起泄漏表现成整组资源缓慢耗尽。第三类缓存回收回调缺失。不少子系统会维护自己的对象池空闲对象攒在池子里等内存压力来了通过 shrinker 回调回收。如果注册缓存时漏写了 shrinker或者 shrinker 实现里没有真正释放对象那这部分内存对回收机制来说就是黑洞。它们在系统空闲时不显眼一旦其他内存被吃紧你会看到回收动作做了但可用内存毫无起色。第四类异步路径丢失清理。工作队列、定时器、任务回调这类异步机制对象被投递出去之后释放点就在回调函数里。如果回调因为异常条件被丢弃或者回调本身有提前返回而没有执行到释放语句释放点就永久丢了。这类问题最难查难点在于代码上的配对关系在时间和上下文上被拉得很远靠人肉 review 基本是海底捞针。1.3 低量、高频、散落系统是被这样一步步拖垮的这三个特征叠在一起后果就是延迟爆发。刚开始分配量小空闲内存完全看不出变化等累积到一定规模内存回收的代价开始被放大。你会先看到 kswapd 的 CPU 占用缓慢爬升然后是 direct reclaim 出现进程分配内存时偶尔卡顿最后可用内存探底OOM killer 出来挑一个占用大的进程干掉。最讽刺的是OOM killer 识别不了泄漏源它只会挑一个倒霉的大进程于是业务同事看到的现象永远是某个无关服务突然被杀而真正的凶手是内核地址空间里一处悄悄膨胀的缓存。这也是为什么泄漏检测一定要前置等你能从现象上确认问题的时候系统已经高强度挣扎了很久业务损失早就造成了。2. 方案选型内核自带调试设施都不够用自研检测器要解决什么2.1 先看一张主流内核内存调试设施对比表动手之前我先把现成方案大略扫了一遍结论挺有意思能沾到边的工具不少但每个都差一口气。先把对比摆出来。设施原理部署成本核心局限kmemleak扫描数据段、栈、寄存器中的指针引用找出不可达对象内核需打开对应配置误报率高全内存扫描开销大slub_debug对象级毒化与追踪能列出未释放对象及分配栈启动参数加重启只能看 cache 层无法直接归因给调用栈KASAN影子内存机制检测越界和释放后使用需要重新编译内核本质是内存安全工具不是泄漏检测跟踪点/动态追踪采集分配释放事件流相对低原始数据量巨大需要自建归因分析kmemleak 是内核自带的老牌方案原理很聪明把每笔分配都记录成对象周期性扫描整个内存空间看看能不能找到指向对象头的指针引用找不到就判定不可达报为候选泄漏。可实际用起来误报会多到让你怀疑人生。对象地址被藏在容器结构内部、经过偏移量计算得到、或者只存在硬件描述符里时扫描经常漏判反过来一些明明长期存活且被使用的对象又可能被误报成泄漏。而且每次扫描都是翻全内存大内存设备上开销非常可观生产环境根本不敢长期开着。slub_debug 走的是另一条路开启后给每个 slab 缓存加管理信息精确告诉你某个缓存里有多少对象被分配但从未释放甚至能拿到分配点的调用栈。但它通常需要改启动参数并重启系统对生产环境很不友好。而且它本质上是给一张静态照片——你不会知道这些未释放对象到底是真的泄漏还是本来就该长期存在。KASAN 则是内存安全方向的主力它的重心是越界访问、释放后使用这类内存损坏问题对分配了不释放这种慢性病作用有限想用还得整个内核重新编译一遍改动面太大。2.2 当时的真实需求逼我走向自研我的目标场景是让测试环境长期压测时自动记录内核分配行为出问题后能快速把嫌疑定位到驱动代码的具体函数。拆开看其实就几条硬指标必须运行时加载和卸载不能动不动就重编内核、重启机器报告必须包含调用栈归因不然和裸的分配计数没区别开销要能容忍连续挂几天输出得是给驱动开发者能直接看的报告而不是几百万条原始事件流。现成方案各有一块短板kmemleak 给候选对象但归因弱slub_debug 要重启KASAN 要重编。倒是内核的分配/释放跟踪点看起来最有潜力它能在不重启的前提下拿到每一笔分配和释放事件剩下的工作就是自己设计一套归因和判定逻辑。于是检测器的技术路线就这么定了——自己做一个轻量内核模块加用户态分析工具把内核空间是否存在泄漏这个问题转化成一组调用栈上的分配释放是否匹配的问题。2.3 给自研检测器定下的四条硬指标最后沉淀下来的需求描述只有四句第一内核侧只做记账不做复杂判断逻辑越简单越不容易在跟踪回调这种原子上下文里出事故第二用户态负责归因和判定改算法不用重新动内核第三默认开启采样采样率可调确保长期观察不伤业务第四报告要有趋势数据因为泄漏判断必须看曲线的斜率而不是看某个瞬间的存量。后面整个实现过程都是围绕这四条展开的。3. 检测器核心实现活对象哈希表、调用栈归因与趋势判定3.1 架构分工内核模块只记账用户态脚本做分析我最终采用的架构是内核采集模块加用户态分析脚本两边职责分得很开。内核侧加载一个模块通过内核提供的跟踪注册接口挂到 kmem 子系统的一组分配/释放跟踪事件上每次分配和释放都进来一笔记录维护一张实时变化的活跃对象表。用户态则是一个定期读取报告节点的工具把内核吐出来的对象快照按调用栈归因计算每个栈上的未释放数量曲线再套检测算法输出嫌疑报告。这么拆的核心原因是安全跟踪回调运行在分配热路径上很多情况下处于原子上下文绝不能在里面做复杂逻辑或者可能睡眠的操作。把判断逻辑放到用户态意味着内核模块只做几件无脑操作——收到事件、写记录、合并哈希表、周期导出快照每步都是确定性的不容易引入死锁或竞态。后续调整检测阈值、改过滤规则只改用户态脚本即可不需要反复加载和卸载模块去折腾内核环境。3.2 核心数据结构一张以分配地址为键的活对象表整个检测器的核心数据结构是一张哈希表我用 C 伪代码把它表示出来struct alloc_record { void *ptr; /* 分配地址同时也是哈希键 */ size_t size; /* 分配大小 */ u32 stack_id; /* 保存的调用栈哈希索引 */ u64 alloc_jiffies; u32 alive_since; /* 离首次扫描经过的轮数 */ struct hlist_node node; }; struct stack_site { u32 stack_id; unsigned long stack[MAX_STACK_DEPTH]; atomic64_t nr_alloc; /* 累计分配次数 */ atomic64_t nr_free; /* 累计释放次数 */ atomic64_t cur_outstanding; /* 当前未释放数 */ };核心逻辑很简单。分配事件进来把地址、大小、调用栈哈希压成一条记录挂到哈希表对应 bucket释放事件进来拿地址找到记录删掉并把对应栈点的已释放计数加一。任意时刻哈希表里剩下的对象就是已经分配且尚未释放的那批。选地址做键而不是选调用栈做键是因为地址唯一分配和释放能精确一对一配对调用栈只是对象的一个属性等到归因阶段再按 stack_id 汇总。这个设计保证了即使同一调用栈大量分配也能统计出准确的分配释放缺口。3.3 调用栈归因让报告直接说出责任函数要回答谁泄漏光有活对象表还不够每个对象必须带上分配路径。实现方法是在分配回调里保存一份栈回溯对栈内容做哈希压缩成 stack_id。释放时不需重新回溯因为对象记录里已经带着栈信息了。关键点在于分配路径是热点路径无条件给每个对象保存完整调用栈会导致性能崩掉所以必须做三件事采样、深度裁剪、按栈去重。我默认只保留栈顶三十二帧。同一个栈第一次出现时把完整栈内容写进 stack_site 表之后再有相同栈的分配只递增计数不再重复保存栈帧。这样栈点表规模收敛运行时间越长新增栈点的频率越低内存占用也稳定在一个合理的上限。还有一层细节是在原子上下文里做栈回溯需要用内核的栈回溯接口不同内核版本接口名有差异编译时做一下版本适配即可。并发安全方面跟踪回调运行在软中断等上下文不能直接怼全局锁。我的做法是每 CPU 维护一个批次缓冲回调只把记录草稿塞进当前 CPU 的本地缓冲攒够一批后由延时工作合并进全局哈希表批量更新能显著减少锁操作次数分配路径上的额外开销基本可以忽略。3.4 泄漏判定算法按增长趋势而非瞬时存量过滤误报内核里有大量本来就要长期存活的对象全局连接表、协议栈预分配池、每 CPU 缓存哪个看起来都像泄漏候选。如果看到有对象没释放就报警检测器会变成纯噪音发生器浪费所有人的时间。我的判定思路是不看瞬时存量只看增长趋势对每个 stack_id 维护一条采样历史每到扫描周期记录一次当前未释放数。正常池子建立后曲线会走平真泄漏的特征是曲线持续单调上升而且上升速率和操作频率正相关。综合下来三条规则同时满足才标记为候选泄漏同一个调用栈在连续至少八轮采样里未释放数只增不减未释放字节总数量超过配置阈值默认八兆字节可按业务场景调整单个对象存活时长超过配置上限默认一小时。三条规则分别过滤三类误报第一过滤偶发抖动第二过滤低量级无害对象第三过滤那种分配后短暂存在但尚未释放的正常对象。实际跑下来这套启发式规则在测试环境的表现远好于闷头扫全量对象误报率基本能压到报告里三五个栈点以内。3.5 开销控制采样、批次合并与栈回溯深度裁剪长期挂机实验里不需要对每一笔分配都记账。我把默认采样率设计为 1/100也就是每 100 次分配记录一次。这个量级下趋势曲线已经足够平滑又不会在高频分配场景把缓冲打爆。释放事件同样按采样率记录配对精度会有些许损失但宏观缺口趋势完全不受影响。需要精确定位时可以把采样率调到 1/1观察窗口缩小到分钟级。开销主要由三个部分构成采样回调本身的 CPU 时间、栈回溯时间、哈希合并时间。实测在高频分配场景下1/100 采样时的额外 CPU 占用可以压在百分之一以内连续跑几天毫无压力。我习惯把精确模式和采样模式做成两个档位平时低频挂机做哨兵发现问题后切到全量做精确定位两全其美。4. 完整实操编译部署、报告解读与一次网卡驱动泄漏复盘4.1 环境检查与内核模块编译加载第一步是确认内核开启了跟踪相关支持。先检查 /sys/kernel/tracing/available_events 里能不能看到 kmem:kmalloc、kmem:kmem_cache_alloc、kmem:kfree 这些事件看不到就得换带对应配置的内核。比较稳妥的方法是直接看内核配置文件确认跟踪点、函数跟踪和 debugfs 都是打开状态加载模块前先确认这些前置条件能省掉后面一大半的排障时间。模块编译用一个最简单的 Makefile 就能搞定obj-m memleak_det.o KDIR : /lib/modules/$(shell uname -r)/build all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean编译前确认当前运行的内核源码树和 headers 版本匹配不然接口对不上编出来的模块根本插不进去。加载命令和参数如下insmod memleak_det.ko sample_rate100 scan_interval_ms60000 \ report_path/sys/kernel/debug/memleak_det/report加载后第一件事是看 dmesg确认跟踪点注册成功、报告节点已经出现。如果注册失败大概率就是前置配置没齐全回第一步重新检查。等到模块正常加载我会手动导出一份空态报告记录静态基线后续看趋势时有这份底做对照会稳很多。4.2 报告字段逐项解读趋势数组怎么用报告不会直接告诉你这里泄漏了它只给出嫌疑栈和趋势数据。一份典型报告片段长这样site #12, stack_id0x1f3c8, outstanding12480, bytes3120000 frees : 1874320 trend : [11900, 12110, 12280, 12390, 12480] status : LIKELY_LEAK stack trace: drv_reset_descriptors0x56/0x90 drv_ring_setup0x2c/0x80 drv_open0x18/0x70我来逐项解释怎么读。trend 数组是最近五轮扫描的未释放数量时间从左往右递增。如果一路涨说明这个调用栈每次进来一批新分配旧的又没释放这是非常典型的泄漏形态。frees 是同一栈点累计释放次数和 outstanding 一起看能估算分配释放缺口到底有多大。status 等于 LIKELY_LEAK 的站点直接把栈上函数翻出来对源码排查范围就从整个系统缩小到几个函数效率完全不是一个量级。4.3 实例复盘一次网卡驱动热拔插泄漏的从症状到修复用一个实际案例把整个流程串起来。某测试平台做嵌入式设备验证外插网卡测试脚本反复执行热插拔加网络吞吐打流。跑了三天之后监控看到可用内存缓慢下降kswapd 的 CPU 占用逐渐升高中间还有一次应用进程被 OOM killer 杀掉。现象完全符合内核泄漏的特征低量高频延迟爆发第一个受害者永远是无辜的进程。我把检测器以 1/10 采样率挂上去观察了一轮完整的插拔周期。半天后报告里出现一个持续上升的栈点栈顶是某驱动里的描述符重置函数趋势从 11900 一路涨到 12480折算下来每次热拔插都会新增几百个未释放对象。按照栈上函数去翻源码问题终于现形接口关闭时函数重新分配了一套描述符集合并替换了指针但旧对象只是被重置没有调用释放接口所有引用在替换那一刻全部丢失。典型的错误分支漏释放每次拔卡稳定触发而且泄漏分散在大量小对象上不用归因工具根本看不出规律。修复就一行替换描述符集合之前先把旧的集合整个释放掉。真正关键的验证环节是修完之后重新加载驱动、重复同样一轮热插拔测试检测器报告里那个栈点的趋势从上升线变成平线未释放数量稳定在一个常数附近。到这一步泄漏才算真正关闭。整个排查从装上检测器到确认修复不到两天比之前的全系统静态分析加反复试错效率高太多了。5. 实测中踩过的坑误报过滤、开销调优与配对难题5.1 误报来源与过滤策略误报主要来自两类对象一类是全局表在观察窗口内缓慢增长但本身正常的比如连接表、路由表另一类是每 CPU 预分配缓存存量看起来很大但曲线是平的。前者骗过趋势判定后者骗过存量阈值。我的过滤手段是按 stack_id 维护一份白名单确认过的正常栈点直接跳过新版本驱动上线后出现新的可疑栈点再逐个重新审视。还有一个心得是不要被单次尖峰骗了。某次压测里我看到一个栈点突然多出几万对象差点让同事去改驱动结果下一轮采样又跌回原值。原因是测试脚本在同一时刻建立了一大批长连接属于正常现象。让报告多走几轮再下结论这是判断泄漏的基本修养。5.2 检测器自身开销的极限调优如果 1/100 采样还是嫌贵可以再往下压两档。第一档是把栈回溯深度从三十二帧降到八帧归因精度会损失一部分但趋势判断基本不受影响第二档是把批次合并的批量调大减少全局哈希表的锁操作频率。要是 1/1000 采样都扛不住说明分配热点实在密集建议只在压测窗口开启检测器而不是长期常驻。检测器的定位是定位工具不是监控告警。它不需要七乘二十四小时全量开着的保证真正的价值在于出问题时能快速给出嫌疑栈。我会在每次版本发布后跑一轮基线对比有问题立刻切精确模式平时则让它在低采样档位待命。5.3 分配和释放配对不上的三类特殊情况实际使用中分配释放事件不是总能完美配对。第一类是对象经过内存池中转分配走某个缓存分配接口释放却走另一个底层释放接口。如果同时挂多个分配事件同一个对象可能被重复记账。解决办法是只挂一组完整配对的事件不要混用不同层级的跟踪点。第二类是直接用页面分配器拿物理页面而不经过普通内核缓存的情况默认跟踪不到。需要额外挂页面分配和页面释放事件把页级分配也纳入活对象表。第三类是同一对象分配和释放走了不同路径比如某些驱动把自己维护的资源池设计成统一从缓存分配但释放时根据对象类型分流到不同清理函数配对逻辑要自己确认清楚再配置。5.4 和 kmemleak 互补验证的实战分工自研检测器适合当第一层漏斗先快速把范围缩到具体栈点再用内核自带的内存泄漏扫描工具做二次验证。自研检测器的优势是归因清晰能直接给函数自带工具的优势是能判断对象是否真的没有任何引用两者结合对驱动开发来说几乎不会给错结论。如果自带扫描工具报某个对象可达但检测器一直显示该栈点没有对应的释放路径那大概率是引用关系藏在硬件描述符或者结构体偏移里需要人工再核对代码。我会把这类案例归档作为后续优化检测器判断逻辑的输入。两种工具互补着用时间长了你对内核对象生命周期的直觉会明显变好。内核内存泄漏检测这件事拼的其实不是一个高深算法而是把搜索问题逐步降维先确认是内核态问题再确定是哪一类对象再确定是哪条调用路径最后落到具体函数。检测器帮我把不知道在哪里变成大概在这一段剩下的读代码功夫并不神奇但搜索空间小了几个数量级做事的心情完全不一样。我自己在每次排查后都会留一份报告存档同一驱动上线新版本时再跑一轮对比这种基线加趋势的习惯比临时抱佛脚有效得多。如果你也被某条说不清道不明的内存下降曲线折磨过不妨照这个思路搭一个轻量工具关键时候真的能救急。