一.问题：
前些日子在工作中遇到一个文件，当rmmod一个模块的时候，在模块的exit函数中阻塞了，rmmod进程杀也杀不掉，永远呆在那里，发现它已经是D(disk sleep)状态了，真的无能为力了吗？我不相信这个事实，所以今天在稍微闲暇的时候换换脑子，终于有了解决办法。
二.分析：
解铃还须系铃人，既然是在内核中出了问题，还是需要在内核中寻找办法，解决这类问题的前提是对内核卸载模块的精确理解，流程都理解透了，害怕找不到原因吗？原因都找到了，办法肯定是有的！ (这也是我从公司学习到的最重要的东西！)， 我按照这个原则，查到了rmmod最终调用的代码：
以上注释了4处，分别解释如下：
情况0： 有其它模块依赖要卸载的模块。模块a是否依赖模块b，这个在模块a加载的时候调用resolve_symbol抉择，如果模块a的symbol在模块b中，则依赖
情况1： 只有LIVE状态的模块才能被卸载。
情况2： 引用计数在有其它模块或者内核本身引用的时候不为0，要卸载就要等待它们不引用为止。
情况3： 这个情况比较普遍，因为模块万一在使用过程中oom或者依赖它的模块oom或者模块本身写的不好有bug从而破坏了一些数据结构，那么可能造成exit函数中阻塞，最终rmmod不返回！
三.尝试一下：
针对情况3，举一个例子来模拟：
然后加载上述模块后，前面的模块就可以卸载了。
四.更深入的一些解释：
针对这个模块导致的无法卸载的问题，还有另一种方解决式，就是在别的module中complete掉这个completion，这个completion当然是无法直接得到的，还是要通过/proc/kallsyms得到这个completion的地址，然后强制转换成completion并完成它：
当然这种方式是最好的了，否则如果使用替换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);