linux - 有没有办法弄清楚什么是使用 Linux 内核模块？

Question

如果我加载一个内核模块并用 列出加载的模块lsmod，我可以获得模块的“使用计数”（引用该模块的其他模块的数量）。不过，有没有办法弄清楚什么在使用模块？

问题是我正在开发的一个模块坚持它的使用计数是 1，因此我不能rmmod用来卸载它，但它的“by”列是空的。这意味着每次我想重新编译和重新加载模块时，我都必须重新启动机器（或者，至少，我想不出任何其他方法来卸载它）。

Answer 1

实际上，似乎有一种方法可以列出声称模块/驱动程序的进程 - 但是，我没有看到它做广告（在 Linux 内核文档之外），所以我会在这里记下我的笔记：

首先，非常感谢@haggai_e的回答；指向函数的指针try_module_get和try_module_put负责管理使用计数 (refcount) 的指针是让我能够追踪该过程的关键。

在网上进一步寻找这个，我不知何故偶然发现了帖子Linux-Kernel Archive：[PATCH 1/2] tracking：减少模块跟踪点的开销；最终指向内核中存在的一个工具，称为（我猜）“跟踪”；相关文档位于Documentation/trace - Linux kernel source tree目录中。特别是，两个文件解释了跟踪工具，events.txt和ftrace.txt。

但是，在运行的 Linux 系统上还有一个简短的“tracing mini-HOWTO” /sys/kernel/debug/tracing/README（另见我真的很厌倦人们说没有文档……</a>）；请注意，在内核源代码树中，该文件实际上是由文件kernel/trace/trace.c 生成的。我已经在 Ubuntu 上对此进行了测试natty，请注意，由于/sys它是由 root 拥有的，因此您必须使用它sudo来读取此文件，如sudo cat或

sudo less /sys/kernel/debug/tracing/README

...这几乎适用于/sys将在此处描述的所有其他操作。

---

首先，这是一个简单的最小模块/驱动程序代码（我从引用的资源中汇总），它简单地创建了一个/proc/testmod-sample文件节点，它返回字符串“This is testmod”。阅读时；这是testmod.c：

/*
https://github.com/spotify/linux/blob/master/samples/tracepoints/tracepoint-sample.c
https://www.linux.com/learn/linux-training/37985-the-kernel-newbie-corner-kernel-debugging-using-proc-qsequenceq-files-part-1
*/

#include <linux/module.h>
#include <linux/sched.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h> // for sequence files

struct proc_dir_entry *pentry_sample;

char *defaultOutput = "This is testmod.";


static int my_show(struct seq_file *m, void *v)
{
  seq_printf(m, "%s\n", defaultOutput);
  return 0;
}

static int my_open(struct inode *inode, struct file *file)
{
  return single_open(file, my_show, NULL);
}

static const struct file_operations mark_ops = {
  .owner    = THIS_MODULE,
  .open = my_open,
  .read = seq_read,
  .llseek   = seq_lseek,
  .release  = single_release,
};


static int __init sample_init(void)
{
  printk(KERN_ALERT "sample init\n");
  pentry_sample = proc_create(
    "testmod-sample", 0444, NULL, &mark_ops);
  if (!pentry_sample)
    return -EPERM;
  return 0;
}

static void __exit sample_exit(void)
{
    printk(KERN_ALERT "sample exit\n");
    remove_proc_entry("testmod-sample", NULL);
}

module_init(sample_init);
module_exit(sample_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Mathieu Desnoyers et al.");
MODULE_DESCRIPTION("based on Tracepoint sample");

该模块可以使用以下内容构建Makefile（只需将其放在与 相同的目录中testmod.c，然后make在同一目录中运行）：

CONFIG_MODULE_FORCE_UNLOAD=y
# for oprofile
DEBUG_INFO=y
EXTRA_CFLAGS=-g -O0

obj-m += testmod.o

# mind the tab characters needed at start here:
all:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

构建此模块/驱动程序时，输出是内核目标文件，testmod.ko.

---

至此，我们就可以准备try_module_get和相关的事件追踪了try_module_put；那些在/sys/kernel/debug/tracing/events/module：

$ sudo ls /sys/kernel/debug/tracing/events/module
enable  filter  module_free  module_get  module_load  module_put  module_request

请注意，在我的系统上，默认情况下启用跟踪：

$ sudo cat /sys/kernel/debug/tracing/tracing_enabled
1

...但是，模块跟踪（特别是）不是：

$ sudo cat /sys/kernel/debug/tracing/events/module/enable
0

现在，我们应该首先制作一个过滤器，它将对module_get, module_putetc 事件做出反应，但仅限于testmod模块。为此，我们应该首先检查事件的格式：

$ sudo cat /sys/kernel/debug/tracing/events/module/module_put/format
name: module_put
ID: 312
format:
...
    field:__data_loc char[] name;   offset:20;  size:4; signed:1;

print fmt: "%s call_site=%pf refcnt=%d", __get_str(name), (void *)REC->ip, REC->refcnt

在这里我们可以看到有一个名为 的字段name，其中包含我们可以过滤的驱动程序名称。要创建过滤器，我们只需echo将过滤器字符串放入相应的文件中：

sudo bash -c "echo name == testmod > /sys/kernel/debug/tracing/events/module/filter"

在这里，首先请注意，由于我们必须调用sudo，我们必须将整个echo重定向包装为sudo-ed的参数命令bash。其次，请注意，由于我们写入的是“父级” module/filter，而不是特定事件（可能是module/module_put/filter等），因此此过滤器将应用于列为module目录的“子级”的所有事件。

最后，我们为模块启用跟踪：

sudo bash -c "echo 1 > /sys/kernel/debug/tracing/events/module/enable"

从这一点开始，我们可以读取跟踪日志文件；对我来说，读取跟踪文件的阻塞、“管道”版本是有效的——就像这样：

sudo cat /sys/kernel/debug/tracing/trace_pipe | tee tracelog.txt

此时，我们不会在日志中看到任何内容 - 所以是时候加载（并使用和删除）驱动程序了（在不同的终端trace_pipe中读取）：

$ sudo insmod ./testmod.ko
$ cat /proc/testmod-sample 
This is testmod.
$ sudo rmmod testmod

如果我们回到trace_pipe正在读取的终端，我们应该会看到如下内容：

# tracer: nop
#
#           TASK-PID    CPU#    TIMESTAMP  FUNCTION
#              | |       |          |         |
          insmod-21137 [001] 28038.101509: module_load: testmod
          insmod-21137 [001] 28038.103904: module_put: testmod call_site=sys_init_module refcnt=2
           rmmod-21354 [000] 28080.244448: module_free: testmod

这几乎就是我们将为我们的testmod驱动程序获得的所有内容 - 引用计数仅在驱动程序加载（insmod）或卸载（rmmod）时发生变化，而不是在我们进行通读时cat。所以我们可以简单地在那个终端trace_pipe中用CTRL+中断读取；C并完全停止追踪：

sudo bash -c "echo 0 > /sys/kernel/debug/tracing/tracing_enabled"

在这里，请注意，大多数示例是指读取文件/sys/kernel/debug/tracing/trace而不是trace_pipe这里。然而，一个问题是这个文件并不意味着是“管道”（所以你不应该tail -f在这个trace文件上运行 a ）；trace但相反，您应该在每次操作后重新阅读。在第一个之后，我们将通过-ing和;insmod获得相同的输出。但是，在 之后，读取文件会给出：cattracetrace_pipermmodtrace

   <...>-21137 [001] 28038.101509: module_load: testmod
   <...>-21137 [001] 28038.103904: module_put: testmod call_site=sys_init_module refcnt=2
   rmmod-21354 [000] 28080.244448: module_free: testmod

...也就是说：此时，insmod已经退出了很长时间，因此它不再存在于进程列表中 - 因此无法通过当时记录的进程 ID (PID) 找到 - 因此我们获得一个空白<...>作为进程名称。因此，在这种情况下，最好记录（通过tee）运行输出。trace_pipe另外，请注意，为了清除/重置/擦除trace文件，只需将 0 写入其中：

sudo bash -c "echo 0 > /sys/kernel/debug/tracing/trace"

如果这看起来违反直觉，请注意这trace是一个特殊文件，并且无论如何都会报告文件大小为零：

$ sudo ls -la /sys/kernel/debug/tracing/trace
-rw-r--r-- 1 root root 0 2013-03-19 06:39 /sys/kernel/debug/tracing/trace

...即使它是“满的”。

最后，请注意，如果我们没有实现过滤器，我们将获得运行系统上所有grep模块调用的日志 - 这将记录任何调用（也包括后台）等，因为那些使用binfmt_misc模块：

...
  tr-6232  [001] 25149.815373: module_put: binfmt_misc call_site=search_binary_handler refcnt=133194
..
  grep-6231  [001] 25149.816923: module_put: binfmt_misc call_site=search_binary_handler refcnt=133196
..
  cut-6233  [000] 25149.817842: module_put: binfmt_misc call_site=search_binary_handler refcnt=129669
..
  sudo-6234  [001] 25150.289519: module_put: binfmt_misc call_site=search_binary_handler refcnt=133198
..
  tail-6235  [000] 25150.316002: module_put: binfmt_misc call_site=search_binary_handler refcnt=129671

...这增加了相当多的开销（在日志数据量和生成它所需的处理时间方面）。

---

在查找此内容时，我偶然发现了 Ftrace PDF 的 Debugging Linux Kernel，它指的是一个工具trace-cmd，它与上面的功能非常相似 - 但通过更简单的命令行界面。trace-cmd还有一个名为KernelShark的“前端阅读器”GUI ；这两个也都在 Debian/Ubuntu 存储库中，通过sudo apt-get install trace-cmd kernelshark. 这些工具可以替代上述过程。

最后，我要注意的是，虽然上面的testmod示例并没有真正显示在多个声明的上下文中的使用，但我使用相同的跟踪过程发现我正在编码的 USB 模块被多次pulseaudio声明USB 设备已插入 - 因此该过程似乎适用于此类用例。

Answer 2

它在Linux Kernel Module Programming Guide上说，模块的使用计数由函数try_module_get和module_put. 也许您可以找到为您的模块调用这些函数的位置。

更多信息：https ://www.kernel.org/doc/htmldocs/kernel-hacking/routines-module-use-counters.html

Answer 3

您所得到的只是哪些模块依赖于哪些其他模块的列表（Used bylsmod 中的列）。您无法编写程序来说明加载模块的原因，是否仍然需要它，或者如果您卸载它以及依赖它的所有东西可能会破坏什么。

Answer 4

你可以试试lsof或fuser。

Answer 5

如果您在没有 --force 选项的情况下使用 rmmod，它将告诉您正在使用什么模块。例子：

$ lsmod | grep firewire
firewire_ohci          24695  0 
firewire_core          50151  1 firewire_ohci
crc_itu_t               1717  1 firewire_core

$ sudo modprobe -r firewire-core
FATAL: Module firewire_core is in use.

$ sudo rmmod firewire_core
ERROR: Module firewire_core is in use by firewire_ohci

$ sudo modprobe -r firewire-ohci
$ sudo modprobe -r firewire-core
$ lsmod | grep firewire
$

Answer 6

尝试 kgdb 并为您的模块设置断点

Answer 7

对于任何想弄清楚为什么他们不能重新加载模块的人，我可以通过以下方式解决这个问题

• 使用“modinfo”获取当前使用的模块的路径
• rm -rfing 它
• 将我要加载的新模块复制到它所在的路径
• 键入“modprobe DRIVER_NAME.ko”。