时钟中断导致的内核模块死锁

   这篇文章是对这几天找的一个BUG的总结，如果理解上有不对的地方，或者有更好的建议，希望看到的朋友能够指出。
  问题是这样的：内核模块中有一个哈希表来维护模块中管理的连接，哈希表是用一个读写锁数组来互斥的，每个锁管理一段哈希表槽位。模块中的处理主要有这几个分支：NF_INET_LOCAL_IN和NF_INET_POST_ROUTING两个钩子点的处理函数，一个是定时器处理函数fcluster_timer_process()。死锁出现在两个地方是在定时器处理函数fcluster_timer_process()中获取写锁时一直阻塞，导致占有CPU时间过长，引发softlockup机制的处理，触发panic操作。
   遇到死锁的问题，首先肯定是怀疑自己的代码逻辑中出现了纰漏，所以再次仔细地检查了代码逻辑，发现不会出现没有释放锁的情况。接下来在代码中添加调试信息，在获取锁的时候进行统计，并且在可能导致没有释放锁的地方都加了调试信息，但是还是没有发现问题。内核开发中遇到这样的问题，真是很头疼。内核太庞大了，就算你的逻辑没问题，也有可能因为对内核机制的某些情况不了解导致操作的时机不对。在用户层应用程序中，有gdb可以查看栈信息，单步调试可以看到执行的逻辑，在内核中有很多东西都要靠源码来分析。现在我把最先想到，也是大部分人都会做的两步操作都做了，而且重复了多次，但是依然找不到问题原因，这时心中真是很烦，很不知所措，不知道下一步该怎么做。
  问题还在，也不能什么也不做，一次次地修改添加调试信息的位置，一次次地打印一些参数和变量的值，但是依然没有进展。在测试的过程中我发现了一个系统参数softlock_panic，可以在内核线程占有CPU时间过长的情况下执行p