linux内核模块的强制删除-结束rmmod这类disk sleep进程

一.问题： 
前些日子在工作中遇到一个文件，当rmmod一个模块的时候，在模块的exit函数中阻塞了，rmmod进程杀也杀不掉，永远呆在那里，发现它已经是D(disk sleep)状态了，真的无能为力了吗？我不相信这个事实，所以今天在稍微闲暇的时候换换脑子，终于有了解决办法。
二.分析： 
解铃还须系铃人，既然是在内核中出了问题，还是需要在内核中寻找办法，解决这类问题的前提是对内核卸载模块的精确理解，流程都理解透了，害怕找不到原因吗？原因都找到了，办法肯定是有的！ (这也是我从公司学习到的最重要的东西！)， 我按照这个原则，查到了rmmod最终调用的代码：

view plain copy to clipboard print ?

1. asmlinkage long sys_delete_module(const char __user *name_user, unsigned int flags)  
2. {  
3.     ...  
4.     if (!list_empty(&mod->modules_which_use_me)) { //0.如果其它模块依赖该模块，则不删除  
5.         /* Other modules depend on us: get rid of them first. */  
6.         ret = -EWOULDBLOCK;  
7.         goto out;  
8.     }  
9.     ...  
10.     if (mod->state != MODULE_STATE_LIVE) { //1.如果模块不是LIVE状态，那么就无法进行下去了，得到的结果是busy  
11.         ...  
12.         ret = -EBUSY;  
13.         goto out;  
14.     }  
15.     ...  
16.     if (!forced && module_refcount(mod) != 0) //2.如果引用计数不是0，则等待其为0  
17.         wait_for_zero_refcount(mod);  
18.     up(&module_mutex);  
19.     mod->exit();     //3.如果在这个里面阻塞了，那就无法返回了  
20.     down(&module_mutex);  
21.     free_module(mod);  
22.     ...     
23. }  

以上注释了4处，分别解释如下：
情况0： 有其它模块依赖要卸载的模块。模块a是否依赖模块b，这个在模块a加载的时候调用resolve_symbol抉择，如果模块a的symbol在模块b中，则依赖
情况1： 只有LIVE状态的模块才能被卸载。
情况2： 引用计数在有其它模块或者内核本身引用的时候不为0，要卸载就要等待它们不引用为止。
情况3： 这个情况比较普遍，因为模块万一在使用过程中oom或者依赖它的模块oom或者模块本身写的不好有bug从而破坏了一些数据结构，那么可能造成exit函数中阻塞，最终rmmod不返回！ 
三.尝试一下： 
     针对情况3，举一个例子来模拟：

view plain copy to clipboard print ?

1. static DECLARE_COMPLETION(test_completion);  
2. int init_module()  
3. {  
4.         return 0;  
5. }  
6. void cleanup_module( )  
7. {  
8.     wait_for_completion(&test_completion);  
9. }  
10. MODULE_LICENSE("GPL");  

编译为test.ko，最终在rmmod test的时候会阻塞，rmmod永不返回了！很显然是cleanup_module出了问题，因此再写一个模块来卸载它！在编译模块之前，首先要在/proc/kallsym中找到以下这行：
f88de380 d __this_module        [XXXX无法卸载的模块名称] 
这是因为modules链表没有被导出，如果被导出的话，正确的方式应该是遍历这个链表来比对模块名称的。
以下的模块加载了以后，上述模块就可以被rmmod了：

view plain copy to clipboard print ?

1. void force(void)  
2. {  
3. }  
4. int __init rm_init(void)  
5. {  
6.         struct module *mod = (struct module*)0xf88de380;  
7.         int i;  
8.         int o=0;  
9.         mod->state = MODULE_STATE_LIVE; //为了卸载能进行下去，也就是避开情况1，将模块的状态改变为LIVE  
10.         mod->exit = force;    //由于是模块的exit导致了无法返回，则替换mod的exit。再次调用rmmod的时候会调用到sys_delete_module，最后会调用 exit回调函数，新的exit当然不会阻塞，成功返回，进而可以free掉module  
11.         for (i = 0; i < NR_CPUS; i++) { //将引用计数归0  
12.                 mod->ref[i].count = *(local_t *)&o;  
13.         }  
14.         return 0;  
15. }  
16. void __exit rm_exit(void)  
17. {  
18. }  
19. module_init(rm_init);  
20. module_exit(rm_exit);  
21. MODULE_LICENSE("GPL");  

然后加载上述模块后，前面的模块就可以卸载了。
四.更深入的一些解释： 
针对这个模块导致的无法卸载的问题，还有另一种方解决式，就是在别的module中complete掉这个completion，这个completion当然是无法直接得到的，还是要通过/proc/kallsyms得到这个completion的地址，然后强制转换成completion并完成它：

view plain copy to clipboard print ?

1. int __init rm_init(void)  
2. {  
3.         complete((struct completion *)0xf88de36c);  
4.         return 0;  
5. }  
6. void __exit rm_exit(void)  
7. {  
8. }  
9. module_init(rm_init);  
10. module_exit(rm_exit);  
11. MODULE_LICENSE("GPL");  

当然这种方式是最好的了，否则如果使用替换exit的方式，会导致前面的那个阻塞的rmmod无法退出。你可能想在新编写的模块中调用try_to_wake_up函数，然而这也是不妥当的，因为它可能在wait_for_completion，而wait_for_completion中大量引用了已经被替换exit回调函数进而被卸载的模块数据，比如：
spin_unlock_irq(&x->wait.lock);
schedule();
spin_lock_irq(&x->wait.lock); 
其中x就是那个模块里面的，既然x已经没有了(使用替换exit的方式已经成功卸载了模块，模块被free，x当然就不复存在了)，刚刚被唤醒运行的rmmod就会oops， 但是不管怎样，一个进程的oops一般是没有问题的，因此还是可以干掉它的，这种oops一般不会破坏其它的内核数据，一般都是由于引用已经被free的指针引起的(当然还真的可能有危险情况哦...)。 既然知道这些rmmod都是阻塞在睡眠里面，那么我们只需要强制唤醒它们就可以了，至于说被唤醒后oops了怎么办？由内核处理啦，或者听天由命！因此考虑以下的代码：

view plain copy to clipboard print ?

1. int (*try)(task_t * p, unsigned int state, int sync);  
2. int __init rm_init(void){  
3.         struct task_struct *tsk = find_task_by_pid(28792); //28792为一个阻塞的rmmod进程，这个模块使用上述的替换exit的方式已经被重新rmmod卸载了，然而第一次的那个rmmod仍然阻塞在哪里，没有睡再去唤醒它了。  
4.         try=0xc011a460;  
5.         (*try)(tsk, TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE, 0); //我们唤醒它，至于它醒了之后干什么，随便吧！  
6.         return 0;  
7. }  
8. void __exit rm_exit(void){  
9. }  
10. module_init(rm_init);  
11. module_exit(rm_exit);  
12. MODULE_LICENSE("GPL");  

然后再ps -e一下，基本没有那个rmmod进程了。一个[State:  D (disk sleep)]的进程这样完蛋了。
     以上代码基本都是硬编码的地址以及进程号，真正的代码应该使用参数来传递这些信息，就会比较方便了！
      既然模块结构都可以拿到，它的任意字段就可以被任意赋值，哪里出了问题就重新赋值哪里！既然内核空间都进入了，导不导出符号就不是根本问题了，就算没有procfs的kallsym，也一样能搞定，因为你能控制整个内存！ 
五.防删除： 
我们可以在自己的模块初始化的时候将其引用计数设置成一个比较大的数，或者设置一下别的模块结构体字段，防治被rmmod，然而别人也可以再写一个模块把这些字段设置回去，简单的使用上述方式就可以干掉你的防删除模块， 这是一个矛与盾的问题，关键是，别让人拥有root权限。 
六.总结： 
代码都拿到手了，流程还看不懂吗？流程都懂了，还怕定位不到问题吗？问题都定位了，还能解决不了吗？只要没有人为因素，事实上任何技术问题都是能解决的（  这是我从公司学习到的最重要的东西 ！  ），所谓的不可能只是规范上的规定或者说既然你误操作了或者你的代码有bug，与其说去按照上述方式搞定它，还不如不搞定它，而是改正你自己的错误！

 

     解决模块由于阻塞而无法删除问题有下面的过程：
1.写一个模块替换exit函数，且设置引用计数为0，状态为LIVE，然后rmmod；
2.强制try_to_wake_up那个rmmod进程，注意不能使用wake_up，因为队列可能已经不在了，而应该直接唤醒task_struct；
3.听天由命！

附：内核缺页 
在do_page_fault中，如果缺页发生在内核空间，最终OOPS的话，会调用die：
die("Oops", regs, error_code);
在die中，如果没有处在中断以及没有设置panic-on-oops的话，最终将以SIGSEGV退出当前进程：
if (in_interrupt())
    panic("Fatal exception in interrupt");
if (panic_on_oops) {
    printk(KERN_EMERG "Fatal exception: panic in 5 seconds/n");
    set_cu rrent_state(TASK_UNINTERRUPTIBLE);
    schedule_timeout(5 * HZ);
    panic("Fatal exception");
}
do_exit(SIGSEGV);
这样，如果唤醒睡眠在模块exit中的rmmod，显然在被唤醒之后，检测变量会导致缺页(由于变量已经被free了)，因此会进入die("Oops"...)，最终退出rmmod进程，这个也是很合理的哦！因此上述的清理D状态的进程还是可以用的。