实际上，似乎有一种方法可以列出要求模块/驱动程序的进程-但是，我还没有看到它的广告（在Linux内核文档之外），因此在这里记下我的笔记：
首先，非常感谢@haggai_e的回答；指向函数的指针try_module_get和try_module_put负责管理使用计数（引用计数）是使我能够跟踪过程的关键。
在网上进一步寻找，我偶然发现了Linux-Kernel Archive：[PATCH 1/2]跟踪：减少模块跟踪点的开销；最终指向内核中存在的设施，即（我猜）“跟踪”；该文档位于目录Documentation / trace-Linux内核源代码树中。特别是，有两个文件解释了跟踪工具events.txt和ftrace.txt。
但是，在运行Linux的系统上也有一个简短的“跟踪mini-HOWTO” /sys/kernel/debug/tracing/README（另请参见，我真的很讨厌别人说没有文档…）；请注意，在内核源代码树中，此文件实际上是由文件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：
#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/filteretc），所以此过滤器将应用于列为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驱动程序获得的所有内容-refcount仅在驱动程序已加载（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-ingtrace和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
...这会增加很多开销（在日志数据量和生成日志所需的处理时间上）。
在查找时，我偶然发现了Ftrace PDF调试Linux内核，它指的是trace-cmd工具，该工具与上述功能几乎类似，但是通过一个更简单的命令行界面。还有一个trace-cmd称为KernelShark的“前端阅读器” GUI ；这两个都还通过以下方式在Debian / Ubuntu存储库中sudo apt-get install trace-cmd kernelshark。这些工具可以替代上述过程。
最后，我只是要注意，虽然上面的testmod示例并未真正显示出在多个声明的上下文中的用法，但是我使用了相同的跟踪过程来发现我正在编码的USB模块在pulseaudio不久之后就被反复声明了所有权。USB设备已插入-因此该过程似乎适用于此类用例。