Linux Kernel 模块内存泄露查找 (2)

来源:互联网 发布:python turtle填色 编辑:程序博客网 时间:2024/03/29 15:18

在之前的一篇博文<<Linux Kernel模块内存泄露的一种查找思路>>中,我介绍了一种查找内核内存泄露的一种方法。这不才几个月,又有客户埋怨:使用了产品5天左右后,Suse服务器由于内存耗尽而Crash。O My God,不会吧,在我机器上跑的好好的哇(程序员常用名言 嘿嘿)。 那么就让我们一起来看看,苦逼的博主是如何确定问题并且找到问题的....

一. 确定问题

第一步,我们要做的是,确定这个问题和产品的Kernel模块有关系。首先根据客户描述,如果停止我们产品,则不会出现内存泄露问题。那确定问题和我们产品有关系,但是和用户态程序还是内核模块程序有关系呢?根据客户提供的Kernel Dump查看Slab占用3.6G。那么十有八九,是产品Kernel模块存在Memory Leak了。

++++++++++++++++++++++++++++++
crash> kmem -i
              PAGES        TOTAL      PERCENTAGE
TOTAL MEM   981585       3.7 GB         ----
      FREE    24987      97.6 MB    2% of TOTAL MEM
      USED   956598       3.6 GB   97% of TOTAL MEM
    SHARED       46       184 KB    0% of TOTAL MEM
   BUFFERS       36       144 KB    0% of TOTAL MEM
    CACHED       10        40 KB    0% of TOTAL MEM
      SLAB   941424       3.6 GB   95% of TOTAL MEM

TOTAL SWAP  1048575         4 GB         ----
SWAP USED      527       2.1 MB    0% of TOTAL SWAP
SWAP FREE  1048048         4 GB   99% of TOTAL SWAP
++++++++++++++++++++++++++++++


但是某程序员,之前不是自信满满的说“在我机器上跑的好好的"嘛,那么就狠狠的打自己的脸吧!!!产品实现了一个内核级别的I/O Hook去进行特定的操作。

博主写了个脚本,不断的拷贝文件,模拟出大量的I/O操作,这样就会不断触发调用产品内核模块的Hook函数。在测试之前记录内存使用情况,先使用如下命令清除系统使用缓存:

SUSE11X64-001:~ # syncSUSE11X64-001:~ # echo 3 > /proc/sys/vm/drop_caches 
然后记录内存使用情况,主要记录空闲内存和Slab使用内存:

+++++++++++++++++++++++++++++++++++++++++++++

SUSE11X64-001:~ # cat /proc/meminfo 
MemTotal:        1989340 kB
MemFree:         1495368 kB
......
Slab:              37752 kB

......

+++++++++++++++++++++++++++++++++++++++++++++
然后等待3天(刚好过个周末~~~),使用如上同样方法查看当前空闲内存和Slab使用内存情况,最后发现3天内消耗大约300M内存,刚好约为Slab增长的内存。这样算下Memory leak Rate大概为4.2 M/hour.  也就是说,如果不是通过脚本模拟出大量的I/O操作,将会有更小的Memory Leak Rate,确实不易发现内存泄露。既然问题确定了,那么结下来就进行Memory Leak分析啦。


二. 问题分析

在对这个问题进行分析之前,我们分析下客户提供的Kernel Dump,Slab中哪种类型的Cache占用了太多的内存:sock_inode_cache占用了大约1.8G内存, dentry大约占用了700多M内存。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

crash> kmem -s

CACHE            NAME                 OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE

......

ffff880138431300 sock_inode_cache         640    2842421   2842524 473754     4k

......

ffff880138c00e00 dentry                   192    3769490   3769880 188494     4k

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

sock_inode_cache在内核中存储socket的内核结构,而dentry则对应文件或者目录在内核中的数据结构,如果你和我一样,对Linux的内核还没有特别精通的情况下,那么首要的怀疑目标就是dentry。在内核模块中会对文件的dentry进行访问,那么如何引起内存泄露的呢?这时有以下两个怀疑的思路:

(1) 采用kmalloc等api申请内存空间然后没有释放;

(2) 在对dentry引用访问后,没有对其引用计数进行释放,比如调用dget之后,并没有相应的调用dput.

然后通过Code Review排除了情况(1),但是针对情况(2)也进行了查看,发现在访问dentry后,都调用了dput减少一次引用计数。这个问题一直深深的困扰着我,一个星期以来都不愿意再看这个问题了,可是问题总归要解决的啊??也想了一些方法,比如使用kmemleak?但是得重新编译所有的Suse内核源码,并且不一定能够很清楚的查询到Memory Leak的原因,鉴于我们产品内核模块的代码量不是很大,最终决定,再一次进行Code Review。2天半的时间,功夫不负有心人,终于找到了根本原因!


三. 根本原因

程序执行流程如下:

(1) 根据文件fd,获取file对象,从file对象中获取path对象,并使用path指针pPath记录path对象地址(path对象中包扩了dentry和vfsmount成员指针)。

(2)程序中需对dentry和vfsmount进行访问,于是采用path_get(pPath)对引用计数加一

(3)调用系统中的原始的close,来关闭文件

(4)进行一系列的操作后,采用path_put(pPath)对dentry和vfsmount引用计数减一

问题就出在第(3)步和第(4)步上:如果只有一个进程对文件打开并进行了访问,然后关闭文件,则进入我们产品的Hook函数,当进入第三步的时候,调用系统原始的close,内核中将进行如下调用过程:close->filp_close->fput->__fput. 可以看到在fput中,如果当前file对象的引用计数只为1的时候,才调用__fput.

void fput(struct file *file){        if (atomic_long_dec_and_test(&file->f_count))                __fput(file);}
一般情况下file对象此时引用计数为1(例外比如一个进程打开文件并且fork)调用__fput,注意其中会将其dentry和mnt指针设置为NULL

static void __fput(struct file *file){        struct dentry *dentry = file->f_path.dentry;        struct vfsmount *mnt = file->f_path.mnt;        struct inode *inode = dentry->d_inode;        might_sleep();        fsnotify_close(file);        /*         * The function eventpoll_release() should be the first called         * in the file cleanup chain.         */        eventpoll_release(file);        locks_remove_flock(file);        if (unlikely(file->f_flags & FASYNC)) {                if (file->f_op && file->f_op->fasync)                        file->f_op->fasync(-1, file, 0);        }        if (file->f_op && file->f_op->release)                file->f_op->release(inode, file);        security_file_free(file);        ima_file_free(file);        if (unlikely(S_ISCHR(inode->i_mode) && inode->i_cdev != NULL &&                     !(file->f_mode & FMODE_PATH))) {                cdev_put(inode->i_cdev);        }        fops_put(file->f_op);        put_pid(file->f_owner.pid);        file_sb_list_del(file);        if ((file->f_mode & (FMODE_READ | FMODE_WRITE)) == FMODE_READ)                i_readcount_dec(inode);        if (file->f_mode & FMODE_WRITE)                drop_file_write_access(file);        file->f_path.dentry = NULL;        file->f_path.mnt = NULL;        file_free(file);        dput(dentry);        mntput(mnt);}
因为在第(2)步我们对dentry和mnt进行了引用计数加1(此时引用计数为2),那么在__fput中调用dput和mntput只会对其引用计数减一,但使用内存并不会进行释放。而理论上应该在第(4)步进行完我们定义的操作之后,对其进行释放。可是!!!我们在第(4)步的时候调用了path_put(pPath)去进行释放,可这时候因为之前调用了原始的close,path中的dentry和mnt指针早已被设置为NULL,所以在第(4)步的时候,dentry和mnt并没有进行引用计数减一,进而也没有释放内存,从而造成了内核的Memory Leak。










4 0
原创粉丝点击