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

可以使用以下内容构建此模块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_put等事件,但只适用于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文件上运行); 但相反,你应该trace在每次操作后重新阅读.在第一个之后insmod,我们将从cat-ing trace和trace_pipe/ 获得相同的输出; 然而,在rmmod阅读trace文件后,将给出:

   <...>-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

...它增加了相当多的开销(在日志数据ammount和生成它所需的处理时间).

在查看此内容时,我偶然发现了Ftrace PDF调试Linux内核,它引用了一个工具trace-cmd,它几乎与上面类似 - 但是通过一个更简单的命令行界面.还有一个trace-cmd名为KernelShark的"前端阅读器"GUI ; 这两个也都在Debian/Ubuntu存储库中sudo apt-get install trace-cmd kernelshark.这些工具可以替代上述程序.

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

它在Linux内核模块编程指南中说,模块的使用计数由函数try_module_get和控制try_module_put.也许您可以找到为模块调用这些函数的位置.