unload module的时候为什么要让所有CPU停止工作

littlenewer

系统用sys_delete_module函数unload module，期间会调用try_stop_module来等待所有其他CPU停止工作。为什么要这么做呢

瀚海书香

回复 1# littlenewer

系统用sys_delete_module函数unload module，期间会调用try_stop_module来等待所有其他CPU停止工作。为什么要这么做呢

这是为了实现put_module和get_module的同步。由于get_module调用的次数远远大于put_module的次数，所以内核使用了一个巧妙的方法来实现get和put的同步，就是把所有的同步任务全部放在put端，get端不需要显示的同步。

Without the stop_machine call, there's no synchronization between
initial get and final put. Things will break.

   

smalloc

LS这回答的怎么感觉不对嘴呢？put_module和get_module通常只由用户的某个动作触发，而不是由硬件自身随机事件触发。
加载一个模块相当在内核空间增加了一些数据，一些代码（中断上下文的，和进程上下文的），顺便还有与硬件相关的一些资源，（改变了外设硬件自身的状态，和与CPU的对应关系）。
当在一个处理器上执行某个unload,这个执行是在进程上下文中触发的，具有较低优先级。所以只能被动等待已经启动的高优先级的任务完成，当然还可能通过主动改变外设硬件使得高优先级的任务从触发的源头不再存在，通常就是要求device转入down状态。
这只是比较明显的。
不明显的却是比较难知道另一个处理器正在执行的任务或访问的数据不属于这个module，更隐秘的是可能执行着其他任务是否与这个module相关（数据相关或事件逻辑相关）。

从中可以看出 安全的加载比较容易，安全的撤离却比较麻烦。 个人觉得原因在于我们可以新增加分散的锁来处理多个并发和同步的要求，但却只能用更详细的层次和高昂关联来记录一切动态，而这样做往往性价比过高。正所谓人在江湖，身不由己。

littlenewer

回2楼：
get_module和put_module的逻辑都很简单，就是分别增加和减少module的reference count，唯一的区别是put_module检查当前module状态并在必要时唤醒unload该module的进程，并没有像你说的同步工作都在put_module完成

回3楼:
停止所有其他CPU的工作之后只做了一件事，就是设置module状态为MODULE_STATE_GOING，说明module正在被删除，完了后马上restart这些CPU。而且module也只会在reference为0的情况下才能被删除，就算其他CPU上执行和module相关的代码也不会造成冲突啊？什么情况下，不停止CPU工作就会产生问题呢

smalloc

回复 4# littlenewer


    看我上文就知道。当CPU B执行某中断的时候，CPU A完全有在可能ref 为0删除。这就崩了。

littlenewer

回复 5# smalloc

你的意思是否是CPU B处于中断上下文并且执行与module相关的代码，但此时CPU A检测ref为0就把module删除了？
首先会不会有这种情况出现。CPU B应该在执行module相关代码前把ref加1，这样就不会有问题。
其次，就算你说的情况出现，那为什么要其他CPU停止工作，检测ref为0并删除module的时候其他CPU已经恢复工作了
   

smalloc

你认为一个CPU在执行一个中断时有义务告诉大家他正在使用某个模块的代码？
或许可以做到。但linux肯定没做。原因前面也说了。
看你的意思好象不是从技术角度反驳我。而是因为看我的回话方式不爽而条件反射的心理驳斥，OK，这是最后一帖。

littlenewer

回复 7# smalloc

似乎你太敏感了，我纯粹为了交流技术而来，对于我不明白的地方提出我的看法而已。
   

瀚海书香

回复 4# littlenewer
可能描述的有问题，看看这个帖子吧。
http://fixunix.com/kernel/341757 ... g-stop-machine.html