Linux 内核模块：何时使用 try_module_get / module_put

Question

我正在阅读 LKMPG（请参阅第 4.1.4 节。取消注册设备 ）并且我不清楚何时使用 try_module_get / module_put 函数。有些 LKMPG 示例使用它们，有些则不使用。

更令人困惑的是，try_module_get 在 2.6.24 源代码的 193 个文件中出现了 282 次，但在 Linux 设备驱动程序 (LDD3) 和基本 Linux 设备驱动程序，它们甚至出现在单个代码示例。

我想也许它们与旧的 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 .

那么什么时候适合使用这些函数和它们是否与特定界面或一组环境的使用相关？

编辑

我加载了sched.c 来自 LKMPG 的示例并尝试了以下实验：

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

这使我相信内核现在有自己的会计，并且获取/放置可能已过时。任何人都可以验证这一点吗？

Answer 1

您基本上永远不必使用 try_module_get(THIS_MODULE);几乎所有此类使用都是不安全的，因为如果您已经在模块中，那么再增加引用计数就为时已晚了——总会有一个（小）窗口，您在模块中执行代码但尚未增加引用数数。如果有人恰好在该窗口中删除了模块，那么您将处于在卸载的模块中运行代码的糟糕境地。

您在 LKMPG 中链接的特定示例，其中代码在 open() 方法中执行 try_module_get() 将通过在 struct file_operations 中设置 .owner 字段在现代内核中进行处理：

struct file_operations fops = {
        .owner = THIS_MODULE,
        .open = device_open,
        //...
};

这将使 VFS 代码引用模块 < em>before调用它，这消除了不安全的窗口 - 要么 try_module_get() 在调用 .open() 之前成功，要么 try_module_get() 将失败并且 VFS 永远不会调用该模块。无论哪种情况，我们都不会从已经卸载的模块中运行代码。

使用 try_module_get() 的唯一好时机是当您想要在调用一个不同模块之前引用它或以某种方式使用它时（例如，就像示例中的文件打开代码一样）上面解释过）。内核源代码中有很多 try_module_get(THIS_MODULE) 的用途，但大多数（如果不是全部）都是应该清除的潜在错误。

您无法卸载 sched 示例的原因是您的

$ tail /proc/sched -f &

命令使 /proc/sched 保持打开状态，并且由于

        Our_Proc_File->owner = THIS_MODULE;

在 sched.c 代码中，打开 /proc/sched 会增加 sched 模块的引用计数，这会导致您的 lsmod 显示的 1 个引用。快速浏览其余代码，我认为如果您通过终止 tail 命令来释放 /proc/sched，您将能够删除 sched 模块。