Linux内核模块:何时使用try_module_get / module_put
我正在阅读LKMPG ( See Section 4.1.4. Unregistering A Device )，我不清楚什么时候使用try_module_get / module_put函数。有些LKMPG示例使用了它们，有些则没有。
更令人困惑的是，在2.6.24源代码中，try_module_get在193个文件中出现了282次，而在Linux Device Drivers ( LDD3 )和Essential Linux Device Drivers中，它们甚至没有出现在一个代码示例中。
我认为它们可能绑定到旧的register_chrdev接口(在2.6中被cdev接口取代)，但它们只一起出现在同一个文件中8次：
find -type f -name *.c | xargs grep -l try_module_get | sort -u | xargs grep -l register_chrdev | sort -u | grep -c .那么，什么时候使用这些函数是合适的，它们是否与特定接口或一组环境的使用有关？
编辑
我从LKMPG加载了sched.c示例，并尝试了以下实验：
anon@anon:~/kernel-source/lkmpg/2.6.24$ tail /proc/sched -f &
Timer called 5041 times so far
[1] 14594
anon@anon:~$ lsmod | grep sched
sched 2868 1
anon@anon:~$ sudo rmmod sched
ERROR: Module sched is in use这让我相信内核现在自己计算，而get/put可能已经过时了。有人能证实这一点吗？
回答 1
Stack Overflow用户
发布于 2011-05-21 13:32:57
基本上不应该使用try_module_get(THIS_MODULE)；几乎所有这样的使用都是不安全的，因为如果您已经在模块中，那么增加引用计数就太晚了--总会有一个(小)窗口，在这个窗口中，您正在执行模块中的代码，但没有增加引用计数。如果有人恰好在该窗口中删除了该模块，那么您将处于在未加载的模块中运行代码的糟糕境地。
在LKMPG中链接的特定示例中，代码在try_module_get()方法中执行.owner ()，这将在现代内核中通过设置结构file_operations中的file_operations字段来处理：
struct file_operations fops = {
.owner = THIS_MODULE,
.open = device_open,
//...
};这将使VFS代码在调用模块之前引用该模块，从而消除了不安全的窗口--要么try_module_get()将在调用.open()之前成功，要么try_module_get()将失败并且VFS永远不会调用模块。在这两种情况下，我们都不会从已经卸载的模块中运行代码。
使用try_module_get()的唯一好时机是当你想在调用或以某种方式使用一个不同的模块之前引用它时(例如，就像我在上面解释的例子中的文件打开代码所做的那样)。try_module_get(THIS_MODULE)在内核源代码中有许多用法，但大多数(如果不是全部)都是应该清除的潜在but。
您不能卸载sched示例的原因是您的
$ tail /proc/sched -f &命令使/proc/sched保持打开状态，并且由于
Our_Proc_File->owner = THIS_MODULE;在Schedul.c代码中，打开/proc/sched会递增sched模块的引用计数，这说明了lsmod显示的1个引用。快速浏览一下其余代码，我认为如果您通过终止您的尾部命令来释放/proc/sched，您将能够删除sched模块。
https://stackoverflow.com/questions/1741415
复制相似问题