想问一下关于在内核定时器超时的时候卸载模块的情况

[TihsLoc]

问题源于一次kernel panic。模块里起了一个定时器，这个定时器里注册的函数用了一块公用的内存（这样好像不太对，但是目前确实没有办法修改），在模块卸载的时候是先释放这块内存再停定时器（del_timer）。panic的日志显示在卸载模块的过程中处理了个软中断，调用了那个定时器注册的函数，objdump后确实就是死在那块内存上。

接下来想解决这个问题。首先是想到调换一下卸载模块时的顺序，先停定时器再释放内存，然后出现了新问题，卸载模块会有一定概率失败，查了下应该是卸载模块的函数阻塞了。。。

所以这里有几个问题求大家解惑：
1. 第一个肯定是想求大家帮忙解决问题，不知道大家有没有遇到类似这种卸载模块被阻塞的问题，可否分享一下分析解决的思路
2. 另外是想知道“卸载模块”在调度里到底是个什么样的存在，居然能被定时器超时给打断，那反过来定时器处理函数超时的时候触发卸载模块这个动作，定时器处理函数会被打断吗？
3. 最后是希望大家能授人渔了，最近总是被这种中断打断来打断去搞得一身狼狈，感觉需要充电，希望大家能分享一下这部分的学习资料，以及遇到这方面问题的时候怎么样在网上检索。对后者尤其迫切，现在感觉百度都不知道该怎么百度

在这里先谢谢大家了！！！

[nswcfd]

2. 应该不会在定时器的超时处理函数里去卸载模块吧…… 用到是del_timer还是del_timer_sync？ 有一种race condition是del_timer被调用的时候timer已经在另个一个core上执行了。 del_timer不等待，而del_timer_sync等待。

[TihsLoc]

引用 1 楼 nswcfd 的回复:

2. 应该不会在定时器的超时处理函数里去卸载模块吧…… 用到是del_timer还是del_timer_sync？ 有一种race condition是del_timer被调用的时候timer已经在另个一个core上执行了。 del_timer不等待，而del_timer_sync等待。

单CPU，应该不存在race condition的情况吧

[nswcfd]

单CPU不会。