频道栏目
首页 > 程序开发 > 软件开发 > C++ > 正文
内核模块中错误调用kernel_thread创建内核线程导致模块无法卸载
2013-01-16 12:58:03           
收藏   我要投稿
 先介绍一下创建线程的大致流程:在模块的初始化函数中,调用netlink_kernel_create来注册自己的netlink协议,然后返回,接收netlink消息的函数为fcluster_netlink_recv,真正的初始化操作是在接收到netlink报文后才做,创建线程的操作也是在fcluster_netlink_recv中,如下图所示:

 

 

调用kernel_thread的语句为:

 

 

[cpp] 

kernel_thread(fcluster_rcv_handoff, NULL, 0);  

按照这样的处理流程,在卸载模块时会提示 "module is in use".通过lsmod命令查看自己的模块,发现引用数为1(模块引用数为0时才能卸载),但是却没有看到是哪个模块在引用。经过多次的重复测试,发现问题就出现在内核线程的创建上。因为如果把kernel_thread的调用放在fcluster_init函数中,这样模块的引用数为0,模块就可以卸载。现在就可以判断,出现模块无法卸载的原因就是调用kernel_thread创建内核线程的时机不对,或者指定的参数不对。

  为了定位问题,开始在不同的情况下增加调试代码来查找问题。

 第一个测试是kernel_thread放在fcluster_init的情况下,在fcluster_rcv_handoff(内核线程的处理函数)、fcluster_init、fcluster_netlink_recv中都加了打印模块引用计数的代码,发现这三个地方的引用计数分别为0、1、1,在这种情况下可以卸载模块。

  第二个测试是kernel_thread放在fcluster_netlink_recv的情况下,在fcluster_rcv_handoff(内核线程的处理函数)、fcluster_init、fcluster_netlink_recv中都加了打印模块引用计数的代码,发现这三个地方的引用计数分别为1、1、1,在这种情况下不可以卸载模块。

  这样就很奇怪了,为什么fcluster_init、fcluster_netlink_recv中引用计数都为1,但是在不同的函数中创建内核线程,模块的引用计数为不同呢?也就是说在fcluster_init中创建内核线程并返回后,模块的引用计数会变为0,但是在fcluster_netlink_recv中创建内核线程并返回后,模块的引用计数仍然为1,想找到问题的原因,源码是最好的工具,所以立马去内核源码中看load_module函数、do_fork函数、netlink_sendmsg函数。为什么要看几个函数?因为fcluster_init函数的调用肯定是在模块的加载过程中,而加载模块的系统调用sys_init_module函数中主要是调用load_module来完成的;而kernel_thread主要是调用do_fork来创建的内核线程;netlink_sendmsg是netlink报文的发送函数,这个函数会调用到fcluster_netlink_recv函数(这个函数注册到netlink_sock类型的netlink_rcv成员。

  首先从load_module入手,通过艰苦的啃代码过程,终于找到在load_module调用的module_unload_init中将模块的引用计数设置为1,在初始化过程中保持对模块的引用,防止卸载模块的操作(这个几乎不太可能,但是模块的初始化函数有可能睡眠)。在load_module完成艰苦的模块加载工作后(/* Do all the hard work */),sys_init_module中会通过do_one_initcall函数来调用模块提供的初始化函数,所以在fcluster_init(我的模块的初始化函数)中模块的引用计数会为0,但是在什么时候模块的引用计数会变为0呢?还是在sys_init_module中,调用module_put来减少模块的引用计数,所以如果kernel_thread的调用放在fcluster_init时,不会造成模块的引用计数在fcluster_init返回模块加载完成后仍为1,这个通过测试的结果也可以看出,但是还不充分,因为还不知道do_fork函数会不会因为调用时机的问题造成模块的引用计数保持为1。

  接下来开始看netlink_sendmsg函数,这个过程就比较简单了,大致的调用流程如下图所示:

 

在这个流程中并没有对模块引用计数加1的操作,可以判断出在调用netlink_sendmsg之前模块的引用计数已经为1了,那只能是在用户层创建套接字的时候了,看看netlink_create函数,果然是在这个函数中,部分代码如下:

 

[cpp] 

if (nl_table[protocol].registered &&  

     try_module_get(nl_table[protocol].module))  

        module = nl_table[protocol].module;  

其中的module就是我的内核模块,具体的可以参见netlink_kernel_create函数。对我的模块引用的释放,要到该套接字释放的时候才会发生,所以问题的原因就在于用户层创建的套接字没有被释放,参见netlink_release函数,至此已经基本可以找到问题的原因了。

 

  用户层在调用socket函数创建我提供的netlink协议类型的套接字时,会调用到netlink_create函数,进而对我注册的模块的引用计数加1。当用户层调用sendmsg发送netlink报文时,会调用到netlink_sendmsg,进而会调用到fcluster_netlink_recv函数,如果这时我在fcluster_netlink_recv中调用kernel_thread,会根据当前的用户进程来创建内核线程,而当前的用户进程打开的文件包括创建的套接字(这个套接字创建的时候会对我的模块的引用计数加1),并且创建内核线程时指定的标志参数为0,这样新创建的内核线程会导致对这个套接字的引用计数加1(参见copy_files函数)。当用户层关闭套接字时,因为该套接字的引用计数不为0,这个套接字也就不会释放,也就不会减少对我的模块的引用计数,导致模块无法卸载。

  为了验证我的推理,通过"lsof -p 5599"(5599为内核线程的id)来验证:

  下面是内核模块可以卸载时的情况:

下面是内核模块无法卸载时的情况:

 

 

 

从两个图中可以看出,无法卸载时最后多了一个sock类型的一行。

怎么解决这个问题呢?要么是在新创建的内核线程中关闭所有的打开的文件,要么是在创建内核线程时指定CLONE_FILES标志,或者在内核线程的处理函数中调用daemonize函数

#define CLONE_FILES    0x00000400    /* set if open files shared between processes */

至于为什么调用kernel_thread时指定CLONE_FILES可以解决这个问题,参见copy_files函数。

 

解决这个问题我也花了不少时间,但是通过这个过程,了解了模块的加载过程,netlink报文的发送和接收、及netlink套接字的创建、内核线程的创建等,所以还是受益匪浅啊。等有时间了,我会把load_module、netlink相关的分析整理一下,贴上来,跟大家分享一下。这个问题要描述的话很绕,很难说清。所以如果有什么疑问的话,可以交流一下。

 

点击复制链接 与好友分享!回本站首页
上一篇:TCP协议发送SKB时ip_summed成员的设置
下一篇:list_for_each_entry宏
相关文章
图文推荐
文章
推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站