关键词：sqllite、meminfo、slabinfo、alloc_calls、nand、SUnreclaim等等。
下面记录一个由于驱动导致的内存泄漏问题分析过程。
首先介绍问题背景，在一款嵌入式设备上，新使用sqllite库进行数据库操作，在操作数据(大量读写操作)一段时间之后，发生OOM现象。
然后OOM会选择进程kill，即使系统中不剩什么进程，仍然内存紧张。
下面就介绍从上往下查找问题，然后在底层掐住RootCause，进而解决问题的分析过程。
1. 问题初步分析
首先怀疑的是sqllite库问题，在PC进行同样的测试未发现内存泄漏。在另一款参考设备上，进行同样的测试，未发现内存泄漏。
以上测试确保了测试程序、sqllite库等一致，仅交叉工具链和平台不一致。
结论：可以基本肯定sqllite库以及测试程序没有问题，可能的问题包括交叉工具链、平台问题。平台问题更大，所以问题集中到具体平台上进行分析。
疑问点：
1. 为何进程退出后，泄漏的内存没有释放？参见分析，是因为SUnreclaim的slab内存不在进程内存统计范围之内。
2. 是否由于工具链不同导致库函数表现不一致？参见分析1，内存泄漏点在内核驱动中。 参见分析2，经过在RAM上运行sqllite测试；单独测试NAND文件系统，得出泄漏和sqllite无关。
3. 是平台内核导致的泄漏吗？参见分析，确定泄漏在kmalloc-4096这个slab中。
2. 具体平台查找内存泄漏方向
定位内存泄漏按照从大到小的思路，即首先看系统内存哪里泄漏，然后再看进程内存哪里泄漏，最后看哪种内存泄漏。
2.1 分析系统内存
首先通过cat /proc/meminfo，然后分析泄漏点。
从MemFree和MemAvailable看，内存将低了235M和228M。
然后看一下下面内存消耗在哪里？可以看出slab消耗了228M，再细节可以看出SUreclaim消耗了228M。基本确定
结论：确定由于Unreclaim类型的slab泄漏导致的内存泄漏。
疑问点：找出具体哪个slab泄漏了？参见分析，在kmalloc-4096这个slab中。 哪个调用的slab申请？参见分析，通过kmalloc-4096的alloc_calls可以知道调用点。
2.2 分析进程内存
通过pmap -X -p `pidof xxx`来获取进程的地址映射空间，可以分析进程内存细节。
结论：通过下面的对比，可以看出进程本身没有导致内存泄漏。所以内存泄漏虽然有此进程导致，但是泄漏点不在进程中。
2.3 分析slab内存泄漏点
既然确定slab导致的泄漏，那么就需要使用slabtop、/proc/slabinfo以及/sys/kernel/slab来分析。
从下面可以看出泄漏点在kmalloc-4096这个slab，这个slab消耗的内存为250M左右。
然后就是去找slab的调用记录，幸运的是系统在/sys/kernel/slab/*/中提供了alloc_calls和free_calls。
alloc_calls:
pidmap_init+0x4e/0x10c age= pid=
con_init+0xf6/0x21c age= pid=
pcpu_mem_zalloc+0x36/0x74 age= pid=
seq_buf_alloc+0x26/0x54 age= pid=
register_leaf_sysctl_tables+0x74/0x1b0 age= pid=
ubifs_mount+0x68/0x15e8 age= pid=
ubifs_mount+0xdaa/0x15e8 age= pid=
nand_scan_tail+0xa2/0x6a8 age= pid=
ubi_attach_mtd_dev+0x9a/0xc38 age= pid=
sourcesink_bind+0x382/0x4c0 age= pid=
vid_dev_probe+0x32/0x1a0 age= pid=
hantrodec_probe+0x56/0x944 age=// pid=
55898 spinand_cmdfunc+0x236/0x52c age=8997/225988/416514 pid=1-202
flow_cache_cpu_prepare.isra.+0x3c/0x74 age= pid=
free_calls:
<not-available> age= pid=
kvfree+0x2a/0x60 age=// pid=-
ubifs_read_superblock+0x690/0xe14 age= pid=
kobject_uevent_env+0xda/0x580 age=// pid=
uevent_show+0x5e/0xf4 age=// pid=-
skb_free_head+0x2c/0x6c age= pid=
结论：从alloc_calls可以看出spinand_cmdfunc中申请了55898次slab，和系统内存泄漏量基本一致。
2.4 分析驱动内存泄漏
通过objdump -S -l -D vmlinux > vmlinux.txt，然后结合反汇编代码，找到spinand_cmdfunc+0x236可以找到具体点。
805829e2: e3f26433 bsr 0x803cf248 // 803cf248 <_end+0xff997448>
805829e6: c4004820 lsli r0, r0,
spinand_cmdfunc():
/home/al/deepeye1000/linux/drivers/staging/mt29f_spinand/mt29f_spinand.c:
spinand_program_page(info->spi, state->row, state->col,
所以问题最终指向了mt29f_spinand.c的806行，spinand_program_page()这个函数里面。
分析此驱动代码，可以看出通过devm_kzalloc()申请的内存没有被释放的点。虽然此内存在模块卸载的时候会被自动释放，但是NAND驱动一般不会被卸载。
结论：确定泄漏点在spinand_program_page()中。
3. 旁证测试
基本上找到的问题点，为了验证上述分析做了几个简单的测试。
3.1 在ramfs中进行sqllite数据库操作
既然泄漏点在NAND驱动中，那么避开在NAND中进行读写操作即可。在/tmp目录下，进行数据库操作，作为对比测试。
同样的软件和平台下，运行同样的业务。
结论：在ramfs中进行操作，没有发生内存泄漏。说明泄漏sqllite操作无关。。
3.2 在NAND上进行文件cp、rm等操作
既然泄漏点在NAND，那么不使用数据库读写，纯文件系统读写如何呢？
经过测试，同样发现SUreclaim内存增加导致的泄漏。
结论：内存泄漏跟NAND上文件操作有关。
为什么之前没有发现内存泄漏问题呢？原来主要业务是运行应用，很少对NAND进行写，即使有写也是偶尔的，发现不了内存泄漏。这种情况在频繁的读写、删除操作下比较容易复现。
4. 解决问题
解决的思路就是确保在函数退出的时候，保证wbuf的内存能够得到释放。
diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 2474d88..
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -, +, @@ static int spinand_program_page(struct spi_device *spi_nand,
#ifdef CONFIG_MTD_SPINAND_ONDIEECC
unsigned int i, j;- wbuf = devm_kzalloc(&spi_nand->dev, CACHE_BUF, GFP_KERNEL);
+ wbuf = kzalloc(CACHE_BUF, GFP_KERNEL);
if (!wbuf)
return -ENOMEM;@@ -, +, @@ static int spinand_program_page(struct spi_device *spi_nand,
retval = spinand_enable_ecc(spi_nand);
if (retval < ) {
dev_err(&spi_nand->dev, "enable ecc failed!!\n");
- return retval;
+ goto exit;
}
}
#else...
-
- return 0;
+exit:
+#ifdef CONFIG_MTD_SPINAND_ONDIEECC
+ kfree(wbuf);
+#endif
+ return retval;
}
5. 验证测试
基于以上的分析过程，构建测试用例：
1. 进行同样的NAND上sqllite数据操作
2. 同样重复cp、rm操作NAND上文件系统
